Selective data encryption using style sheet processing

ABSTRACT

A method, system, and computer program product for selectively encrypting one or more elements of a document using style sheet processing. Disclosed is a policy-driven augmented style sheet processor (e.g. an Extensible Stylesheet Language, or “XSL”, processor) that creates a selectively-encrypted document (e.g. an Extensible Markup Language, or “XML”, document) carrying key-distribution material, such that by using an augmented document processor (e.g. an augmented XML processing engine), an agent can recover only the information elements for which it is authorized. The Document Type Definition (DTD) or schema associated with a document is modified, such that the DTD or schema specifies a reference to stored security policy to be applied to document elements. Each document element may specify a different security policy, such that the different elements of a single document can be encrypted differently (and, some elements may remain unencrypted). The key distribution material enables a document to be encrypted for decryption by an audience that is unknown at the time of document creation, and enables access to the distinct elements of a single encrypted document to be controlled for multiple users and/or groups of users. In this manner, group collaboration is improved by giving more people easier access to information for which they are authorized, while protecting sensitive data from unauthorized agents. A key recovery technique is also defined, whereby the entire document can be decrypted by an authorized agent regardless of how the different elements were originally encrypted and the access protections which were applied to those elements.

RELATED INVENTIONS

This application is related to the applications having Ser. No.09/422,492 entitled “Selective Data Encryption Using Style SheetProcessing for Decryption by a Client Proxy”, Ser. No. 09/422,537entitled “Selective Data. Encryption Using Style Sheet Processing forDecryption by a Group Clerk”, and Ser. No. 09/422,431 entitled“Selective Data Encryption Using Style Sheet Processing for Decryptionby a Key Recovery Agent”, all assigned to the same assignee and filedconcurrently herewith on Oct. 21, 1999.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a computer system, and deals moreparticularly with a method, system, and computer program product forselectively encrypting one or more document elements using style sheetprocessing. The document may be an Extensible Markup Language (XML)document, and the style sheet processor may be an Extensible StylesheetLanguage (XSL) processor.

2. Description of the Related Art

Cryptography is a security mechanism for protecting information fromunintended disclosure by transforming the information into a form thatis unreadable to humans, and unreadable to machines that are notspecially adapted to reversing the transformation back to the originalinformation content. The cryptographic transformation can be performedon data that is to be transmitted electronically, such as an electronicmail message or an electronic document requested by a user of theInternet, and is equally useful for data that is to be securely stored,such as the account records for customers of a bank or credit company.

The transformation process performed on the original data is referred toas “encryption”. The process of reversing the transformation, to restorethe original data, is referred to as “decryption”. The terms “encipher”and “decipher” are also used to describe these processes, respectively.A mechanism that can both encipher and decipher is referred to as a“cipher”.

Use of a “key” during the encryption and decryption processes helps makethe cipher more difficult to break. A key is a randomly-generated numberfactored into operation of the encryption to make the result dependenton the key. The value used for the key in effect “personalizes” thealgorithm, so that the same algorithm used on the same input dataproduces a different output for each different key value. When the valueof this key is unknown to unauthorized persons, they will not be able toduplicate or to reverse the encryption.

One of the oldest and most common security systems today is what isknown as a “private key” or “symmetric” security system. Private keysystems involve two users, both of whom have a shared secret (orprivate) key for encrypting and decrypting information passed betweenthem over a network. Before communications can occur, the two users mustcommunicate in some secure manner to agree on this private key to ensurethe key is known only to the two users. An example of a cipher used forprivate key security is the Data Encryption Algorithm (“DEA”). Thisalgorithm was developed by scientists of the International BusinessMachines Corporation (“IBM”), and formed the basis of a United Statesfederal standard known as the Data Encryption Standard (“DES”). Privatekey systems have a number of drawbacks in an open network environmentsuch as the Internet, however, where users will conduct allcommunications over the open network environment and do not need or wantthe added overhead and expense of a separate secure means of exchangingkey information before secure network communications occur.

To address the limitations of private key systems, security systemsknown as “public key”, or “asymmetric”, systems evolved. In a public keysystem, a user has a key pair that consists of a private key and apublic key, both keys being used to encrypt and decrypt messages. Theprivate key is never to be divulged or used by anyone but the owner. Thepublic key, on the other hand, is available to anyone who needs to useit. As an example of using the key pair for encrypting a message, theoriginator of a message encrypts the message using the receiver's publickey. The receiver then decrypts the message with his private key. Thealgorithm and the public key used to encrypt a message can be exposedwithout comprising the security of the encrypted message, as only theholder of the associated private key will be able to successfullydecrypt the message. A key pair can also be used to authenticate, orestablish the identity of, a message originator. To use a key pair forauthentication, the message originator digitally signs the message (or adigest thereof) using his own private key. The receiver decrypts thedigital signature using the sender's public key. A common means ofpublishing a public key to be used for a particular receiver is in anX.509 certificate, also known as a “digital identity”.

Public key encryption is generally computationally expensive, havingnumerous exponentiation operations. It also requires much longer keymaterial than a symmetric key algorithm to provide equivalent security.Hence it is used sparingly, preferably only for cryptographic operationsthat need its unique properties. Symmetric key encryption is more widelyused for bulk data encryption/decryption, because it demands less of theCPU, using primarily repeated shift, rotate, exclusive OR, and tablelookup operations.

Public and symmetric key encryption methods are often combined. Oneexample of their combination is the Secure Sockets Layer (SSL), and itsfollow-on replacement known as Transport Layer Security (TLS). Anotherexample is the Internet Key Exchange (IKE) protocol of the IP SecurityProtocol, as defined in the Internet Engineering Task Force (IETF)document RFC 2411, “IP Security Document Roadmap”.

In general, both the SSL and IKE protocols perform similar steps. Firstthe parties are mutually authenticated using public key encryption,during which process X.509 certificates are exchanged and encryptionalgorithms negotiated. Then the first party creates a symmetric key andencrypts it using the second party's public key. The encrypted symmetrickey is transferred to the second party, which then decrypts it using itsprivate key. This process of negotiation and key transfer is called a“key agreement”. A key agreement may have a predetermined expirationtime, and the protocol may include means for subsequent key agreements.After completing a key agreement, the symmetric key can be used toperform efficient bulk data encryption between the parties.

The majority of current encryption techniques deal with encrypting anentire document for transmission to a known audience. Little attentionhas been given to the business-to-business security requirements oftoday's complex networking environments, where a document must flowasynchronously through a number of intermediate agents such astranscoders, gateways, and firewalls (where each agent may have a uniqueneed to know different aspects of the transmitted information) and wherethe audience cannot be precisely determined beforehand.

Furthermore, key distribution in a complex, multi-business networkingenvironment is a critical issue. If two parties repeatedly exchangeencrypted data using the same key over and over again for successivedocuments (such as might occur when two businesses need to exchangetransactional information in an on-going manner), then it makes iteasier for a third party to crack the encryption and discover thedocument content of all the repeated transmissions. Thus, there must bea secure method for periodically distributing new keys betweencommunicating parties. Likewise, if keys are changed and the subsequentkeys are varied by an easily computed function of the base shared key,then the repeated transmissions would be easier to crack than if arandom key were selected for each new transmission. It is thereforepreferable to use a randomly-generated key value for each subsequentkey. It is also preferable to use a new key for each document, toincrease the security of the document. If a random key is used for eachdocument, then a secure technique must exist to distribute this key tothe receiver with a minimum of system overhead.

A document may be securely stored in an encrypted file system, or anencrypted file may be stored on a server where it can be accessed onlyby those possessing the decryption key. For the same reasons discussedabove, each document should be encrypted with a different random key anda means must exist of distributing this key to all those who need toread the document.

A plaintext document can be protected during transmission by encryptingthe transport-layer connection using SSL or TLS, or by creating anencrypted data-link-layer tunnel using the IP Security Protocol (IPSec)or the Layer 2 Tunneling protocol (L2TP). However, such methods ofprotection only apply to connection-oriented systems where an end-to-endsession exists between the sender and receiver at the time oftransmission. Both offer techniques whereby the encryption key hidingthe data is changed at regular intervals over the life of the session.

These approaches (encrypting the file, the file system, or the session)are not useful in some situations, however. In situations where severalagents (such as a series of intermediaries including gateways,transcoders, and/or firewalls) must handle the document in succession,it may be necessary for each intermediary to have access to some of theencrypted data elements within a file or document. This implies that theintermediaries need the key for decrypting the file, making protectionof the key a logistical nightmare. When encryption is performed at thelevel of the entire document, then an intermediary that receives the keywill have access to the entire document rather than just those elementsthat may be needed for this intermediary's particular function, thusincreasing the potential for unauthorized agents to gain access to thesecurity-sensitive information.

Another problem situation for existing techniques (such as relying on anencrypted session) is transmitting documents through store-and-forwardsystems such as message queuing (MQ), where the sender and receiverconnect to a store-and-forward server at different times and neverestablish end-to-end connections to one another. In an MQ system, evenif the connection between the sender and the MQ server is encrypted, andthe connection between the MQ server and the receiver is encrypted,nevertheless the document is stored as plaintext on the MQ server forsome period of time. This obviously creates a security exposure unlessaccess to the MQ server is strictly controlled. It is unreasonable forthe creator of security-sensitive information to rely on the MQ server(possibly including multiple such servers in a network path) to providesufficient protection for preventing access to his plaintext document.

The existing approaches which have been described above (encrypting thesession, encrypting the file system, or encrypting the file) are alsonot useful in the situation where the target client device has suchlimited CPU processing power that it cannot perform the necessaryencryption/decryption operations, or performs them so slowly as to makethe system unusable. Electronic commerce is becoming increasinglyimportant in today's global economy. Electronic commerce, also known as“e-commerce” or “e-business”, involves the secure transfer ofbusiness-critical data to selected recipients over non-secure publicnetworks such as the Internet. Consider the overall life cycle of ane-business document. In the general case, the document passes throughvarious hands or agents, which differ greatly in terms of their “need toknow specific data elements within the document. Consider an employeerecord or document generated by an Enterprise Resource Planning (ERP)software application. This employee document is an example of a singledocument that may contain elements needing different types of accessprotection. The document may contain public information such as theemployee's name, employee serial number, and date of hire. Thisinformation may need to be in plaintext form so the document issearchable in a database. The employee document may also contain salaryinformation that only managers may see. It may also contain payrollinformation that only the payroll department should view. Finally it maycontain medical data that only medical personnel should see. Inaddition, the employee should be able to view the entire contents of hisown employee document. Besides transit over a network, the document maypass through agents that store and forward the data, such as a companyrepository which records and time stamps transmitted and receiveddocuments for legal purposes, an e-mail system, an e-mail archive, ane-mail screening program on a firewall, and so forth. It is unreasonableto fully trust all the intermediaries in such an electronic commercesystem. Furthermore, at the time of document construction, it isvirtually impossible to foresee who all the ultimate consumers (i.e.requesting users or application programs) of the data may be, or whichintermediary agents may handle the data, and yet the data must beprotected. It is also unreasonable to create a customized document foreach potential consumer, or to create a customized document upon eachrequest by a different consumer, where the customized document wouldcontain only those elements for which the consumer is authorized.

Commonly assigned (Ser. No. 09/240,387, filed Jan. 29, 1999, titled“Method, System, and Apparatus for Selecting Encryption Levels Based onPolicy Profiling” suggests tagging data elements in Extensible MarkupLanguage (“XML”) documents with field-level or record-level securityinformation. By inspecting this security-level information andconsulting directory entries concerning an individual's accessprivileges, a server responding to a document request suppresses anydocument elements for which the requester is unauthorized, determinesthe encryption algorithm and key length required by the most restrictiveremaining element (i.e., the remaining element having the highest-levelsecurity requirements), and encrypts the entire resulting filtereddocument accordingly. This invention does not some the problem ofencrypted documents with multiple authorized receivers and agents, eachwith a different need-to-know (i.e. it does not restrict the ability toread certain fields of a document to certain individuals or groups). Nordoes it address the problem of client devices with insufficientprocessing power to decrypt received documents.

Several solutions for disturbing encrypted key material along with theencrypted document to which the key applies are known in the art. TheSMIME industry standard defined by the IETF is used in secure emailtransmission, providing an encapsulation of digitally signed andencrypted objects. (See SMIME charter information that is available fromthe IETF for more information.) The Lotus Notes® software uses aproprietary implementation for key distribution. “Lotus Notes” is aregistered trade of Lotus Development Corporation and/or IBM, and moreinformation about Lotus Notes is available by contacting IBM.) However,neither of these existing approaches suggests that individual documentfields be encrypted (and other fields not encrypted). Nor do theysuggest having different authorized viewing communities, or usingmultiple and/or different encryption algorithms and/or keys fordifferent fields in a document that need different levels of security(nor is a capability for distributing multiple keys per documentavailable).

Accordingly, what is needed is a technique with which security policycan be efficiently enforced in a complex distributed network computingenvironment, incorporating many complex factors such as those describedabove.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a technique forenforcing security policy efficiently in a complex distributednetworking environment.

Another object of the present invention is to provide this technique ina manner that enables data to be protected throughout the businessprocess, and throughout transmission between agents in a network pathfrom a document server to a document receiver, making security-sensitiveinformation in the document visible only to those agents having a needto know the information while protecting the information from disclosureto other parties.

Yet another object of the present invention is to provide this techniquewhereby each of the different elements within a single document may usea different security policy, including the ability to use differentsecurity algorithms, keys, and key lengths from one element to another.

Still another object of the present invention is to provide thistechnique by applying style sheets to documents encoded in tag languagessuch as the Extensible Markup Language.

A further object of the present invention is to provide a keydistribution technique which enables a different key to be used for eachencrypted document or document element, where each key used can bedistributed to all document receivers without creating a securityexposure.

Another object of the present invention is to provide this keydistribution technique in a manner that enables an encryption key to berecovered whether the encrypted document resides in a file system or isin a queue en route to its target audience.

A further object of the present invention is to provide a selective dataencryption technique that reduces the amount of data that must beencrypted to provide a given level of security, thereby improving theperformance of security processing for client devices with limitedcapabilities.

Still another object of the present invention is to provide a techniquefor recovering the key(s) used to encrypt elements of a document.

Another object of the present invention is to provide these techniquesin a backward-compatible manner, such that existing style sheetscontinue to function properly.

Other objects and advantages of the present invention will be set forthin part in the description and in the drawings which follow and, inpart, will be obvious from the description or may be learned by practiceof the invention.

To achieve the foregoing objects, and in accordance with the purpose ofthe invention as broadly described herein, the present inventionprovides a method, system, and computer program product for enforcingsecurity policy using style sheet processing. In one embodiment, thistechnique comprises: providing an input document; providing one or morestored policy enforcement objects, wherein each of the stored policyenforcement objects specifies a security policy to be associated withzero or more elements of the input document; providing a Document TypeDefinition (DTD) corresponding to the input document, wherein the DTDhas been augmented with one or more references to selected ones of thestored policy enforcement objects; executing an augmented style sheetprocessor; receiving an encrypted output document at a client device;executing an augmented document processor, thereby creating a resultdocument; and rendering the result document on the client device.Executing the augmented style sheet processor preferably comprises:loading the DTD; resolving each of the one or more references in theloaded DTD; instantiating the policy enforcement objects associated withthe resolved references; executing selected ones of the instantiatedpolicy enforcement objects during application of one or more stylesheets to the input document, wherein a result of the executing selectedones is an interim transient document reflecting the execution;generating one or more random encryption keys; encrypting selectedelements of the interim transient document, wherein a particular one ofthe generated random encryption keys may be used to encrypt one or moreof the selected elements, while leaving zero or more other elements ofthe interim transient document unencrypted; encrypting each of the oneor more random encryption keys; and creating the encrypted outputdocument, where the encrypted output document comprises the zero or moreother unencrypted elements, the selected encrypted elements, and theencrypted encryption keys. Executing the augmented document processorpreferably comprises decrypting the received output document for anindividual user or process on the client device.

Alternatively, the DTD may be replaced by a schema.

The interim transient document may comprise one or more encryption tagsidentifying elements needing encryption. The input document may bespecified in an Extensible Markup Language (XML) notation, and theoutput document may be specified in this XML notation. The style sheetsmay be specified in an Extensible Stylesheet Language (XSL) notation.

The stored policy enforcement objects may further comprise executablecode for overriding a method for evaluating the elements of the inputdocument, and wherein executing selected ones further comprisesoverriding this method for evaluating. This method may be a value-ofmethod of the XSL notation, and overriding the value-of method may be bysubclassing this value-of method. This overriding may further comprisegenerating encryption tags, and inserting the generated encryption tagsinto the interim transient document to surround elements of the interimtransient document which are determined to require encryption.Encrypting selected elements may further comprise encrypting thoseelements surrounded by the inserted encryption tags.

Each of the instantiated policy enforcement objects may furthercomprise: a specification of a community that is authorized to view theelements associated with the security policy; and an encryptionrequirement for the elements associated with the security policy. Thisencryption requirement may further comprise specification of anencryption algorithm. Or, the encryption requirement may furthercomprise specification of an encryption algorithm strength value, and/orspecification of an encryption key length. The encryption requirementmay have a null value to indicate that the specified security policydoes not require encryption.

Encrypting the encryption keys may further comprise encrypting adifferent version of each of the random encryption keys for each of oneor more members of each of zero or more of the communities which usesthis encryption key, and wherein each of the different versions isencrypted using a public key of the community member for which thatdifferent version was encrypted.

Encrypting the selected elements may use a cipher block chaining modeencryption process.

This technique may further comprise: creating a key class for eachunique community, wherein the key class is associated with each of theencrypted elements for which this unique community is an authorizedviewer, and wherein the key class comprises: (1) a strongest encryptionrequirement of the associated encrypted elements; (2) an identifier ofeach member of the unique community; and (3) one of the differentversions of the encrypted encryption key for each of the identifiedcommunity members. Generating the one or more random encryption keys maygenerate a particular one of the random encryption keys for each of thekey classes, wherein each of the different versions in a particular keyclass is encrypted from the generated encryption key generated for thekey class. Encryption of the selected elements may use that one of theparticular random encryption keys which was generated for the key classwith which the selected element is associated.

Decrypting the output document may further comprise: determining zero ormore of the communities of which the individual user or process is oneof the members; decrypting, for each of the determined communities, thedifferent version of the random encrytion key which was encrypted usingthe public key of this one member, wherein the decrypting uses a privatekey of the one member which is associated with the public key which wasused for encryption, thereby creating a decrypted key; and decryptingselected ones of the encrypted elements in the output document using thedecrypted keys, wherein the selected ones of the encrypted elements arethose which were encrypted for one of the determined communities.Rendering the output document may further comprise rendering thedecrypted selected ones and the other unencrypted elements.

Or, decrypting the output document may further comprise: determiningzero or more of the key classes which identify the individual user orprocess as one of the members; decrypting, for each of the determinedkey classes, the different version of the random encrytion key in thekey class which was encrypted using the public key of this one member,wherein the decryption uses a private key of the one member which isassociated with the public key which was used for encryption, therebycreating a decrypted key; and decrypting selected ones of the encryptedelements in the output document using the decrypted keys, wherein theselected ones of the encrypted elements are those which were encryptedfor the key class. The rendering may further comprise rendering thedecrypted selected ones and the other unencrypted elements.

The rendering may further comprise rendering a substitute text messagefor any of the selected encrypted elements in the output document whichcannot be decrypted by the decryption of the output document.

The inserted encryption tags may surround either values of the elementsor values and tags of the elements.

The present invention will now be described with reference to thefollowing drawings, in which like reference numbers denote the sameelement throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a computer workstation environment in whichthe present invention may be practiced;

FIG. 2 is a diagram of a networked computing environment in which thepresent invention may be practiced;

FIG. 3 depicts a Document Type Definition (DTD) that has been augmentedwith security policy information, according to the preferred embodimentsof the present invention;

FIGS. 4A-4C illustrate an example of an employee document on which thepresent invention may operate; an interim representation of the employeedocument after being augmented with security information; and the samedocument after encryption has been performed;

FIGS. 5A-5C depict examples of record or object formats that may be usedwith the preferred embodiments of the present invention;

FIG. 6 provides an overview of the components involved in the preferredembodiments of the present invention, and the general data flows betweenthem; and

FIGS. 7 through 12 illustrate flow charts depicting the logic with whichthe preferred embodiments of the present invention may be implemented.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a representative workstation hardware environment inwhich the present invention may be practiced. The environment of FIG. 1comprises a representative single user computer workstation 10, such asa personal computer, including related peripheral devices. Theworkstation 10 includes a microprocessor 12 and a bus 14 employed toconnect and enable communication between the microprocessor 12 and thecomponents of the workstation 10 in accordance with known techniques.The workstation 10 typically includes a user interface adapter 16, whichconnects the microprocessor 12 via the bus 14 to one or more interfacedevices, such as a keyboard 18, mouse 20, and/or other interface devices22, which can be any user interface device, such as a touch sensitivescreen, digitized entry pad, etc. The bus 14 also connects a displaydevice 24, such as an LCD screen or monitor, to the microprocessor 12via a display adapter 26. The bus 14 also connects the microprocessor 12to memory 28 and long-term storage 30 which can include a hard drive,diskette drive, tape drive, etc.

The workstation 10 may communicate with other computers or networks ofcomputers, for example via a communications channel or modem 32.Alternatively, the workstation 10 may communicate using a wirelessinterface at 32, such as a CDPD (cellular digital packet data) card. Theworkstation 10 may be associated with such other computers in a localarea network (LAN) or a wide area network (WAN), or the workstation 10can be a client in a client/server arrangement with another computer,etc. All of these configurations, as well as the appropriatecommunications hardware and software, are known in the art.

FIG. 2 illustrates a data processing network 40 in which the presentinvention may be practiced. The data processing network 40 may include aplurality of individual networks, such as wireless network 42 andnetwork 44, each of which may include a plurality of individualworkstations 10. Additionally, as those skilled in the art willappreciate, one or more LANs may be included (not shown), where a LANmay comprise a plurality of intelligent workstations coupled to a hostprocessor.

Still referring to FIG. 2, the networks 42 and 44 may also includemainframe computers or servers, such as a gateway computer 46 orapplication server 47 (which may access a data repository 48). A gatewaycomputer 46 serves as a point of entry into each network 44. The gateway46 may be preferably coupled to another network 42 by means of acommunications link 50 a. The gateway 46 may also be directly coupled toone or more workstations 10 using a communications link 50 b, 50 c. Thegateway computer 46 may be implemented utilizing an Enterprise SystemsArchitecture/370 available from IBM, an Enterprise SystemsArchitecture/390 computer, etc. Depending on the application, a midrangecomputer, such as an Application System/400 (also known as an AS/400)may be employed. (“Enterprise Systems Architecture/370” is a trademarkof IBM; “Enterprise Systems Architecture/390”, “Application System/400”,and “AS/400” are registered trademarks of IBM.) The gateway computer 46may also be coupled 49 to a storage device (such as data repository 48).Further, the gateway 46 may be directly or indirectly coupled to one ormore workstations 10.

Those skilled in the art will appreciate that the gateway computer 46may be located a great geographic distance from the network 42, andsimilarly, the workstations 10 may be located a substantial distancefrom the networks 42 and 44. For example, the network 42 may be locatedin California, while the gateway 46 may be located in Texas, and one ormore of the workstations 10 may be located in New York. The workstations10 may connect to the wireless network 42 using a networking protocolsuch as the Transmission Control Protocol/Internet Protocol (“TCP/IP”)over a number of alternative connection media, such as cellular phone,radio frequency networks, satellite networks, etc. The wireless network42 preferably connects to the gateway 46 using a network connection 50 asuch as TCP or UDP (User Datagram Protocol) over IP, X.25, Frame Relay,ISDN (Integrated Services Digital Network), PSTN (Public SwitchedTelephone Network), etc. The workstations 10 may alternatively connectdirectly to the gateway 46 using dial connections 50 b or 50 c. Further,the wireless network 42 and network 44 may connect to one or more othernetworks (not shown), in an analogous manner to that depicted in FIG. 2.

Software programming code which embodies the present invention istypically accessed by the microprocessor 12 of server 47 or anintermediary such as gateway 46 (hereinafter referred to simply as anintermediary)—and by workstation 10 in several embodiments of thepresent invention—from long-term storage media 30 of some type, such asa CD-ROM drive or hard drive. The software programming code may beembodied on any of a variety of known media for use with a dataprocessing system, such as a diskette, hard drive, or CD-ROM. The codemay be distributed on such media, or may be distributed to users fromthe memory or storage of one computer system over a network of some typeto other computer systems for use by users of such other systems.Alternatively, the programming code may be embodied in the memory 28,and accessed by the microprocessor 12 using the bus 14. The techniquesand methods for embodying software programming code in memory, onphysical media, and/or distributing software code via networks are wellknown and will not be further discussed herein.

A user of the present invention may connect his computer to a serverusing a wireline connection, or a wireless connection. Wirelineconnections are those that use physical media such as cables andtelephone lines, whereas wireless connections use media such assatellite links, radio frequency waves, and infrared waves. Manyconnection techniques can be used with these various media, such as:using the computer's modem to establish a connection over a telephoneline; using a LAN card such as Token Ring or Ethernet; using a cellularmodem to establish a wireless connection; etc. The user's computer maybe any type of computer processor, including laptop, handheld or mobilecomputers; vehicle-mounted devices; desktop computers; mainframecomputers; etc., having processing (and optionally communication)capabilities. The remote server and the intermediary, similarly, can beone of any number of different types of computer which have processingand communication capabilities. These techniques are well known in theart, and the hardware devices and software which enable their use arereadily available. Hereinafter, the user's computer will be referred toequivalently as a “workstation”, “device”, or “computer”, and use of anyof these terms or the term “server” refers to any of the types ofcomputing devices described above.

In the preferred embodiments, the present invention is implemented asone or more computer software programs. The software may operate on aserver, on a user workstation, and/or on an intermediary in a network,as one or more modules (also referred to as code subroutines, or“objects” in object-oriented programming) which are invoked uponrequest. The server or intermediary may be providing services in anInternet environment, in a corporate intranet or extranet, or in anyother network environment.

The present invention defines a novel technique for selectivelyenforcing security policy in a distributed network computing environmentusing style sheet processing. A policy-driven augmented style sheetprocessor is used to create a selectively-encrypted document carryingkey-distribution material, such that by using an augmented documentprocessor an agent can recover a Document Object Model (“DOM”)containing only the information elements for which the agent isauthorized. In the preferred embodiments, the augmented style sheetprocessor is an augmented Extensible Stylesheet Language (“XSL”)processor, the document is an XML document, and the augmented documentprocessor is an augmented XML processing engine. Documents encoded inthis fashion support improved group collaboration models, giving morepeople easier access to information for which they are authorized, whileprotecting sensitive data from unauthorized agents. The presentinvention also provides a novel, efficient way to recover encrypted datafrom documents encoded according to the inventive techniques disclosedherein.

A number of terms to be used in the description of the preferredembodiments will now be defined.

-   -   “Community” refers to the collection of viewers to which a given        authorization policy applies, in regard to a specific class of        information. In the employee record example previously        discussed, “all managers” or “employee plus all medical        personnel” are examples of potential communities. In the        preferred embodiments, a community is represented by the        distinguished names (DNs) of one or more individuals and/or        groups comprising that community. For each DN there is a        corresponding X.509 certificate. In the preferred embodiments of        the present invention, whenever a group can be represented by a        single certificate, that group certificate is preferred in place        of all the individual certificates for all the group's members        (as will be described in more detail with reference to FIG. 7A).    -   “Element visibility” is a policy that defines to whom (where        this may be people and/or application programs or processes) an        element defined by a DTD (or alternatively, by a schema) should        be made visible, and under what conditions. According to the        preferred embodiments, a visibility policy defines (1) the        minimum encryption strength required for the element, and (2)        the community that is authorized to see the element's value.        “Minimum encryption strength” can be resolved to a specific        encryption algorithm and key length (e.g. by consulting a        directory or lookup table, etc.). Encryption that is stronger        than required can satisfy an element visibility policy, but        weaker-than-required encryption is never satisfactory. (Note        that while the preferred embodiments discuss dynamically        determining an algorithm and key length to provide the minimum        encryption strength which has been specified in a policy object,        in an alternative approach the algorithm identifier and key        length may be specified directly in the policy object without        deviating from the scope of the present invention. In this case,        a determination as to which of multiple algorithms and        associated key lengths provides a stronger encryption may be        made by using a look-up table in which the pertinent values are        arranged in a particular order of strength, by coding the        relative strength values directly into an implementation, etc.        It will be obvious to one of ordinary skill in the art how the        descriptions of the preferred embodiments are to be modified        when using this alternative approach.)    -   “Group” refers to a collection of one or more individuals or        processes (i.e. application entities) who are authorized members        of a community. Preferably, a group is represented by a named        object in an LDAP directory. (Alternatively, other storage        repositories may be used.) The information stored for a        particular group comprises: (1) the group's X.509        certificate; (2) a pointer (or other identifier) identifying a        group clerk or clerks; and (3) pointers to each group member.        (The X.509 certificates for each group member are then contained        in, or pointed to from, the group member's stored information.)        If a proxy or agent is authorized to act on behalf of a group or        group member, the proxy is also identified as a group member.    -   “Group clerk” refers to a process that maintains the private key        for a group, rather than having each group member store the        private key. The clerk is contacted during the decryption of        secure document content being served to a group member, and        provides information for use in the decryption process. Each        group has at least one clerk. Multiple clerks may be identified        for a single group for purposes of hot backup and/or load        distribution, where each such clerk has equivalent processing        privileges on behalf of a particular group.

Commonly assigned U.S. Pat. No. 6,585,778 (Ser. No. 09/385,899, filedAug. 30, 1999), titled “Enforcing Data Policy Using Style SheetProcessing”, discloses a technique for controlling the content of adocument using stored policy information. This invention, referred tohereinafter as the “referred invention”, is incorporated herein byreference. The present invention defines an extension to the storedpolicy objects defined in this referenced invention, whereby the storedpolicy objects further comprise attributes specifying the elementvisibility information described above. These extensions will bedescribed in more detail with reference to FIGS. 7A through 7C.

The employee record example previously discussed will be used toillustrate the benefits as well as the implementation of the presentinvention. Suppose a company maintains a database (or other repository)of information about its employees, and further suppose that the storedrecord for each employee comprises the employee's name, employee serialnumber, data of hire, current salary, and any pertinent medicalconditions. FIG. 3 depicts an example of a DTD 300 that may be used todescribe the data in the record for an employee of this company. As iswell known in the art, a DTD is a definition of the structure of an XMLdocument, and is encoded in a file which is intended to be processed,along with the file containing a particular XML document, by an XMLparser. The DTD tells the parser how to interpret the document which wascreated according to that DTD. (Note that while the present invention isdescribed with reference to information specified in a DTD, theinformation may be specified in other semantically equivalent forms. Inparticular, the schemes which are currently being standardized by theWorld Wide Web Consortium or “W3C” may be used instead of DTDs. Refer to“XML Schema Part 1: Structures”, which is available from the W3C, formore information. References herein to a DTD are to be interpreted asapplying equally to a schema.) This DTD 300 includes entries for theemployee name (“empl_name”) 350, the employee serial number (“ser_nbr”),“date_of_hire” 370, current salary (“curr_salary”) 380, and“medical_condition” 390.

This DTD 300 has been augmented with data policy information which,according to the present invention, includes element visibilityinformation that can be used to selectively encrypt the associateddocument elements, thereby restricting access to the values of thedocument elements. As defined by the referenced invention, data policy(as extended by the present invention to include element visibility) canbe associated with a document's data structures by modifying the DTD forthe document to specify the URI (Uniform Resource Indicator) of eachapplicable policy. Three different data policies, each with differentelement visibility, will be used to illustrate the employee recordexample. Each policy will now be discussed, along with the elementvisibility information specified in the stored policy objects.

The policy used for the employee name, serial number, and date of hireis to allow unrestricted access to these data items. Data policyinformation to enforce this unrestricted access policy (as well as anypolicies used with the present invention) is preferably stored in adirectory database, such as an LDAP database. The stored policy can thenbe retrieved by sending a message to the database engine, specifying theURI of the desired information, as will be discussed in more detailbelow. An example URI that may be used to retrieve the “unrestricted”policy information for this example is shown at element 332. Note thatXML parameter entity substitution has been used in this example DTD 300,whereby the relatively long URIs 312, 322, 332 are specified as thevalue associated with shorter entity names 311, 321, 331. These shorternames are then used within the attribute list declarations, such as “%unrestricted” 355 in the empl_name declaration 350. This approach hasthe advantage of reducing the number of characters within the DTD when aURI is used repeatedly, and also makes the attribute list declarationsmore intuitive and easier to read. (As will be obvious, the URIs mayalternatively be replicated throughout the DTD without deviating fromthe scope of the present invention.) Note that the URIs 312, 322, 332have been depicted as relative distinguished names (RDNs) for the storeddata policy information. These RDNs are simply a unique identifier forstoring the object in a directory. Alternative storage techniques (andidentifications thereof) may be used without deviating from the scope ofthe present invention.

Because access to the employee name, serial number, and date of hire isto be unrestricted, the values of these document elements will not beencrypted in the document to be returned to a document requester. Thus,the minimum security strength and community attributes of the policyobject stored at location 332 are preferably set to null values (toindicate that encryption is not required).

Another policy used with the employee record example is to limit accessto an employee's current salary to the employee himself, any managers ofthe company, and any employees within the company's human resources (HR)department. The URI for this policy has been given the entity name“empl_mgr_hr”311, and is specified 385 in the attribute list declarationfor curr_salary 380. The stored policy object located at URI 312 willspecify the encryption strength deemed to be appropriate for projectingthis employee salary information from unauthorized access. The communityattribute in the policy object will preferably comprise threedistinguished name values one for the individual employee, one for thegroup comprising all managers, and one for the group comprising allemployees in the HR department. (Alternatively, a separate DN entrycould be specified for each member of the managers group and/or eachmember of the HR department, but as previously stated, it is preferableto represent all members of a group by a group DN when the group DN isavailable.)

The third policy of this example is used with the medical conditionsinformation. Suppose that access to this information is to be restrictedto the employee to which it pertains, and any employee working in themedical department. Information for enforcing this policy (including itselement visibility restrictions), which has been given the entity name“empl_medical” 321, is stored at URI 322. The policy is associated withthe medical_condition 390 element by specifying 395 the URI 322 throughits entity name 321. The stored policy object located at URI 322 willspecify the encryption strength appropriate for protecting theemployee's medical_condition information, and the community attribute inthe policy object will preferably comprise two distinguished namevalues—one for the individual employee and one for the group comprisingall employees in the medical department. (As described above, a separateDN entry could alternatively be specified for each member of the medicalgroup, without deviating from the scope of the present invention.)

The solution used in the preferred embodiments—of specifying a datapolicy URI within a data element's attribute list declaration—allows oneto encode the most complex arrangement possible, that being a differentpolicy and different element visibility for each data element (eventhough this situation is likely never to occur in actual use). As can beseen from the example DTD in FIG. 3, the preferred embodiments usestandard DTD markups with a special convention. In this manner,processes unaware of the policy convention will still see totally validXML syntax which passes all standard validation tests when therespective document contains policy markups. A beneficial side effect ofthis is that if the document generated by a data source uses a URI DTDreference (such as element 405 of document 400 in FIG. 4A, which refersto the storage location of the example DTD 300 of FIG. 3), then anenterprise data policy administrator can cause data policy and elementvisibility restrictions to be applied to such generated documents simplyby modifying the referenced DTD (to add policy definitions and elementvisibility, or perhaps change the policy definitions and elementvisibility which have already been added). No change to the code whichgenerates the XML source documents at the data source needs to be madeto cause the appropriate encryption and access restrictions to beapplied.

By convention, the DTD policy markup of the preferred embodiments uses afixed attribute (see, e.g., 354 of FIG. 3) from a policy namespace (see352 of FIG. 3) to indicate the URI of the policy which is to be appliedto an XML element. As is known in the art, using a namespace prefixenables differentiation among tags that might otherwise be consideredduplicates. Setting a fixed value guarantees that the value of thisattribute (such as the value 355 of attribute 353) will be available tothe XSL processor whenever it processes the element (such as theempl_name element 351).

FIG. 4A illustrates a simple source document 400 resulting fromretrieval of the employee record information for a particular employee(identified by name at 402 and by serial number at 404), before theprocessing of the present invention has occurred. This source document400 contains plaintext information for all document elements of theemployee record, including the security-sensitive elements “curr_salary”408 and “medical_condition” 410 (which are to be encrypted using thestored policy objects specified at 385 and 395 of FIG. 3, respectively).The example DTD of FIG. 3 would then be used by an augmented XSLprocessor, as described below, to apply the desired data policy andelement visibility rules to produce a selectively-encrypted version ofthis document 400 before publishing the encrypted document or sendingthe encrypted document to the requesting client. Note that there is nopolicy markup nor any reference to policy in the document 400, andhence, as stated above, there was no need to modify the XML emitter ofthe document-generating application at the data source.

Skipping for now the discussion of FIG. 4B (comprising FIGS. 4B1 and4B2) and proceeding to FIG. 4C (comprising FIGS. 4C1 and 4C2), arepresentative example of a selectively-encrypted document containingthe information from source document 400 is shown at 450. Using thepolicy and element visibility examples discussed with reference to FIG.3, if the requesting user is the employee 402, this user will be able torecover (i.e. decrypt) the protected values of both curr_salary 408 andmedical_condition 410 from the encrypted fields 452, 454 (where thesefields 452, 454 contain values used for illustrate purposes only) ofdocument 450 which is transmitted in response to his request. Inaddition, because selectively-encrypted documents are not customized fora particular requesting user according to the present invention, butrather carry sufficient key distribution material to enable access byany authorized user, employee 402 will be able to recover the protectedvalues 453, 455 from fields 452, 454 even if he was not the originalrequester of the encrypted document. Similarly, a user who is a managerin this company or who works in the HR department will be able torecover the value 453 of encrypted field 452 if he receives document450, because these users are within the authorized community forcorresponding document element 408, and a user in the medical departmentwill be able to recover the value 455 of encrypted field 454. If a userwho is not a manager, is not the individual employee, and does not workin either the HR or medical department receives encrypted document 450,this user will only be able to view the values of unrestricted documentelements 402, 404, and 406, even though the values of the curr_salaryand medical_condition elements are contained within this user's copy ofthe document 450. The manner in which an augmented style sheet processorapplies the data policy and visibility rules to yield these resultsaccording to the present invention will be discussed below. (Style sheetprocessing may perform additional changes to source document 400 in theprocess of generating an encrypted document, such as formatting theemployee record information into a predetermined layout or performtarget-specific transformations unrelated to data policy and elementvisibility, using techniques which are known in the art and do not formpart of the present invention.)

According to the preferred embodiments of the present invention, theprocess of selectively encrypting a document is implemented as twological phases. The first phase is referred to herein as the“preprocessing” phase. The augmented DTD 300 described with reference toFIG. 3, a source document such as document 400 of FIG. 4A, and thestored policy objects and their visibility rules (not shown) are used asinput to the preprocessing phase. The second phase is referred to hereinas the “post processing” phase. Encrypted document 450, including itsembedded key distribution material 460, is generated as a result of thepost processing phase.

FIGS. 5A-5C show preferred embodiments of the format of records orobjects (referred to hereinafter as “objects” for ease of reference)that are created and used during the processing of the present inventionto perform the selective encryption technique disclosed herein, andwhich are also used during the corresponding decryption processes. Thecontent and format of each of these objects will now be described. (Themanner in which these objects are created and used during the processingof the preferred embodiments will be described in more detail below withreference to the logic in FIGS. 7-12.)

FIG. 5A depicts the layout of an object referred to herein as a “keyobject”. According to the preferred embodiments, one version 500 of thiskey object is used internally by the encryption processing of thepresent invention, and a second version 510 is transmitted along withthe encrypted object with which it was used. Both versions 500, 510include one distinguished name (DN) 501. Version 500 of the key objectincludes an X.509 certificate 502 a corresponding to this DN, whileversion 510 replaces the certificate with a “keyIdentifier” 502 b (seeRFC 2459, “Internet X.509 Public Key Infrastructure Certificate and CRLProfile”) which can be used to locate the certificate 502 a inconjunction with the DN via a directory or other repository. Finally,both versions 500 and 510 include an encrypted symmetric key 503. TheX.509 certificate 502 a contains the public key 505 that was used tocreate the encrypted symmetric key 503 (as will be discussed in moredetail below). The entity named in the certificate's “subject” field 504owns the private key corresponding to public key 505, and can use thisprivate key to decrypt the symmetric key 503. (Note that the value ofthe certificate's subject field 504 may be different from the value ofthe DN field 501.) The keyIdentifier 502 b is a shorthand “fingerprint”that can be used to identify the certificate 502 a to which itcorresponds, for example, when searching through the certificates in akey ring or chain, or when searching through certificates returned by adirectory or database search. As is well known in the art, X.509certificates are quite large. Using the shorthand notation 502 b whentransmitting an encrypted document saves space in the encrypteddocument, while conveying semantically equivalent information. However,the entire certificate 502 a may alternatively be transmitted with theencrypted document, rather than using version 510 of the key object andits key identifier 502 b, without deviating from the inventive conceptsdisclosed herein.

As is known in the art, some secure transmission protocols require onedigital certificate for encrypting data, and another for use in creatinga digital signature. The preferred embodiments of the present inventionassume an SSL session is being used, wherein only a single certificateis needed. It will be obvious to one of skill in the art how thedescription of the preferred embodiments must be modified when using twodifferent certificates. In such two-certificate cases, the certificate502 a represents the encryption certificate.

Key objects 500, 510 are initially built during the preprocessing phaseof the present invention. The encrypted symmetric key value 503 iscreated in the post processing phase.

FIG. 5B shows the format of an object referred to herein as a“preprocessing key class” object 520. Preprocessing key class objectsare used internally by the present invention during both thepreprocessing and post processing phases. Each preprocessing key classobject 520 comprises an encryption strength identifier 521 (which can beresolved to identify a particular encryption algorithm and a key length,for example by consulting a directory or lookup table), a key class 522,and an unencrypted symmetric key 523. The value of symmetric key field523 is created during the post processing phase.

FIG. 5C depicts the format of an object referred to herein as a “keyclass” object 530. A key class defines a community that is authorized toaccess an element, and the type of encryption to be performed on thatelement. More than one element may share a single key class, providedthe community members are identical among the sharing elements. Each keyclass object 530 comprises an identification of the key class 531, anencryption algorithm identifier 532 (identifying the algorithm to beused for document elements associated with this key class 531), a keylength 533, an optional field 534 specifying any other hints that may beneeded to execute the algorithm, and one or more key objects (depictedgenerally in FIG. 5C as 535, 536, . . . 539).

Key class objects 530 corresponding to each preprocessing key classobject 520 are built during the post processing phase, and inserted bythe post processing phase into the DOM root of the document which hasbeen encrypted using these key class objects. (See reference numbers461, 462 of FIG. 4C.)

A key object 535, 536, . . . 539 will exist in a particular key classobject 530 for each community member within the key class 531. Recallthat a key object 500 or 510 is created for each DN 501, and that eachsuch key object includes an encrypted symmetric key 503. Thus, a keyclass object 530 for a key class 531 having 3 community members willinclude 3 key objects 535, 536, 539, and therefore will have 3 differentencrypted symmetric key values 503 (that is, a different symmetric keyvalue for each community member). For the employee record example wherethe individual employee, managers, and HR department employees comprisethe 3 members of the authorized community for viewing current salaryinformation, key class object 530 will include key objects with distinctencrypted keys 503 for each of these members. These 3 differentsymmetric key values are created from the single unencrypted key value523 stored in the preprocessing key object 520. The public key 505 fromthe key object for each community member is used to generate thedifferent symmetric key values. To decrypt the curr_salary information,the processing on behalf of a member of the managers group locates themanagers key object among objects 535, 536, 539 by comparing themanagers group DN to DN values 501, retrieves the encrypted symmetrickey value 503 from the appropriate key object, and decrypts thissymmetric key using the private key for the managers group. Thisdecrypted key can then be used to decrypt the curr_salary information.Similarly, when a member of the HR department wishes to access thecurr_salary, the DN for the HR group is compared to the DN values inobjects 535, 536, 539 to locate the key object for the HR group. Theencrypted key value 503 is then retrieved from that key object, anddecrypted with the HR group's private key. This decrypted symmetric keyis then used by the HR group member to decrypt the curr_salary value.

It is in this manner that selectively-encrypted documents createdaccording to the present invention securely distribute key material thatcan be used for decryption by an audience that is unknown at the time ofdocument creation.

The preferred embodiments of the present invention will now be discussedin more detail with reference to FIGS. 6 through 12. FIG. 6 provides anoverview of the software components used in several of the preferredembodiments. FIGS. 7-12 depict the logic that may be used to implementthe preferred embodiments.

In FIG. 6 there are shown an electronic commerce (“eCommerce”) back-endserver 605, an electronic commerce infrastructure 625, an electroniccommerce client 655 (sometimes also referred to as a server, when actingin its role as proxy on behalf of a browser client), a standard browserclient 675, and a program client 680. Three processes are shown in theeCommerce server 605: an XSL preprocessor 610 and an XSL postprocessor620 according to the present invention, and a transcoding proxy 615. TheXSL preprocessor 610 performs the preprocessing phase of the encryptionprocess, and the XSL postprocessor (which may be the same softwarecomponent as the preprocessor 610) performs the post processing phase.Processes contained within the eCommerce infrastructure 625 include anadministrator application 630, a Certificate Authority 635, an LDAPdirectory 640, various web servers 645, a message queuing or othertransport infrastructure 650, and a group clerk 670. Processes withinthe eCommerce client 655 include an XML preparser 660 (defined by thepresent invention to decrypt selectively-encrypted documents, as will bedescribed in more detail) and a group client 665. In one embodiment ofthe present invention, program client 680 is part of eCommerce client655. Alternatively, program client 680 can be an independent entityanalogous to the browser client 675, served by the eCommerce client 655in its server role.

Note that while several components of FIG. 6 are described in terms of“eCommerce”, this is for purposes of illustration and not of limitation.The present invention may be used advantageously with documents havingsecurity-sensitive information that is not commercial in nature.

The function of the eCommerce back-end server 605 is to createselectively-encrypted documents, and in particular,selectively-encrypted XML documents. In the preprocessing phase, the XSLpreprocessor 610 queries the directory 640 to obtain the DTD as well asdata policies and visibility rules for various document elements. Whilethe preferred embodiments use an LDAP directory as previously stated, itwill be understood by those skilled in the art that some other type ofdirectory or data repository could be substituted without deviating fromthe scope of the present invention; accordingly, an LDAP directory 640is used for purposes of illustration and not of limitation. Thepreprocessor 610 also queries the LDAP directory 640 to resolve thosepolicies into a specific encryption strength (e.g. an enumerated value)and a community, and to obtain the X.509 certificates belonging tocommunity members. At the conclusion of the preprocessing phase,preprocessor 610 passes a working representation of the data, such as aDOM tree representation thereof to the next processing stage, such as atranscoding proxy 615, if present, for further processing, otherwisedirectly to the XSL postprocessor 620. The intermediate stage 615 passesits completed output to the XSL postprocessor 620 defined according tothe present invention. During the post processing phase, XSLpostprocessor 620 contacts the LDAP directory 640 to resolve encryptionstrength to a specific encryption algorithm and key length (if thisinformation was not directly specified in the policy object), and toobtain a key identifier corresponding to an X.509 certificate. When theselectively-encrypted XML document has been built by eCommerce Server605, the document is made available to users who may request it (such asby storing it on Web servers 645), sent to other locations using atransport mechanism such as message queuing 650, and so forth.

The transport and storage details are not germane to this invention,other than the observation that since any sensitive parts of thedocument are now encrypted, there is no need for message queuing orother servers or agents who will handle the XML data to have specialencryption support to protect the document's contents; thesecurity-sensitive document elements are already protected. Furthermore,agents that need to examine specific document fields, e.g. fortransaction routing purposes, can either be authorized to decrypt onlythose fields, or those fields can be left in the clear.

An administration application 630 defined according to the presentinvention (to be discussed in detail below with reference to FIG. 12)interacts with the LDAP directory 640, the certificate authority 635,the browser client 675, the program client 680, the group clerk 670, andthe eCommerce client 655 in performing its functions. As will be morefully explained with reference to FIG. 12, the administrator can create,modify, or delete a group; create, modify, or delete an individualentity (such as a browser client 675, a program client 680, anelectronic commerce client 655 acting in its capacity as a proxy/serverfor a browser client 675, or a group clerk 670); assign an entity to agroup; remove an entity from a group; reassign, renew, or revoke acertificate for a group or an individual entity; create, modify, ordelete a data policy; create, modify, or delete a community definition;create, modify, or delete an encryption strength definition; create,modify, or delete element visibility information in a data policy; orcreate, modify, or delete a DTD.

XML preparser 660 attempts to decrypt selectively-encrypted XML data.For key objects locked using a group key, preparser 660 contacts a localgroup client 665 component. The group client 665 contacts the LDAPdirectory 640 to locate the clerk defined for the group. Then the groupclient 665 contacts the group clerk 670 to get the key objectdeciphered. The group clerk 670 contacts the LDAP directory 640 toascertain the X.509 certificate(s) associated with the requester and itsagents (one or more of the following: the eCommerce client 655 itselfacting on its own behalf or as a proxy, the browser client 675, and/orthe program client 680). Clerk 670 also queries the LDAP directory 640to validate whether a given entity is a member of a given group. In oneembodiment of the present invention, the group clerk 670 and theeCommerce client 655 are implemented on the same hardware platform.

The logic with which the preferred embodiments of the present inventionmay be implemented will now be discussed with reference to theflowcharts in FIGS. 7-12. FIGS. 7A-7C depict the process with which adocument may be selectively encrypted, according to the presentinvention. In one preferred embodiment, an individual user (who may bean authorized member of at least one community for which the documentwas selectively encrypted) receives the encrypted document on his clientworkstation, and executes a decryption process on that workstation. Thisscenario is illustrated in the logic of FIGS. 8A and 8B. In anotherpreferred embodiment, a user's workstation may have insufficientprocessing power to perform the decryption process of the presentinvention, or it may be desirable to avoid changing the user'sworkstation environment such that the code of the present invention canbe executed locally, so a client proxy performs the decryption processon behalf of the user. This scenario is illustrated in the logic ofFIGS. 9A and 9B. In yet another preferred embodiment, the encrypteddocument is received by a member of a group, where the group may be anauthorized member of a community which has access to at least oneelement of the selectively-encrypted document. The manner in which thedecryption process is performed for this embodiment is depicted in FIGS.10A through 10C. In another preferred embodiment, an authorized usersuch as a systems administrator may need to recover the keys which wereused to encrypt a document which may have been stored, e.g., in acompany repository maintained for legal purposes. The manner in whichthis key recovery is advantageously performed according to the presentinvention is shown in FIGS. 11A and 11B. Finally, FIG. 12 depicts thelogic with which an administrator or administration process sets up andadministers the secure document system of the present invention.

Encryption

The selective encryption process depicted in FIGS. 7A-7C operates inlogical phases, as previously described, a preprocessing phase and apost processing phase. During the preprocessing phase (FIG. 7A), datapolicies and element visibility restrictions are loaded from storedpolicy objects and analyzed. Standard style sheet processing is theninvoked (FIG. 7B) to mark those elements in the source document whichrequire encryption. (Alternatively, the processing of FIG. 7B may beperformed by the augmented style sheet processor of the presentinvention, as an extension of the code written to perform thepreprocessing phase.) Finally, during the post processing phase,encryption is applied to the elements which have been tagged and the keydistribution material is inserted into the DOM tree for distributionwith the selectively-encrypted document (FIG. 7C).

The preferred embodiments of the present invention perform the selectiveencryption process using an XSL processor that has been augmented toapply data policy and element visibility restrictions, as previouslystated. FIGS. 7A and 7C illustrate flow charts depicting the additionallogic with which this specially-instrumented XSL processor operates.(The logic of the existing XSL processing has not been shown. It will beobvious to one of skill in the art how to incorporate the logic of FIGS.7A and 7C into the existing XSL processor logic.)

The purpose of the preprocessing phase depicted in FIG. 7A is todetermine the elements of the source document to be encrypted, and tobuild the key classes to be used during the encryption process. Theprocessing of this phase begins at Block 700, and operates upon aparticular source document (such as document 400 of FIG. 4A). Thisprocess may be invoked in response to a client request for the document(as part of the process of returning the requested document to theclient), or in advance of such a request (where the resulting encrypteddocument will then be stored to await a subsequent client request). Notethat references herein to a requesting “client” refer equally to thecase where the response is to be delivered for rendering to a human useror where the response is to be delivered to an executing applicationprogram or process.

In Block 700, the policy-enhanced DTD for the source document isretrieved from a directory or other storage repository. The preferredembodiments assume that data policy is stored in a repository (such asthe LDAP directory referenced by policy URIs 312, 322, 332 of FIG. 3) asexecutable policy object code. Using the examples of FIGS. 3 and 4, thedocument being processed is source document 400 of FIG. 4A. The DTDreference 405 is located by the processing of Block 700, and thisreference 405 is used to retrieve the DTD 300. Block 705 then retrievesan element definition (such as the empl_name definition 350) from theDTD. Block 710 retrieves (using the URIs such as 312, 322, and 332) andinstantiates the policy object referenced from the DTD elementdefinition.

A policy object is preferably written for each specific element type tobe processed, whether the element is to be encrypted or not. As definedin the referenced invention, each policy object preferably operates byspecifying executable code to overload existing XSL processor methods,and is written to be executed as a “plug-in” to the XSL processor(wherein the plug-in concept is well known in the art). In particular,the preferred embodiments overload the XSL “value-of” method.Preferably, this overloading will be done by subclassing the existingvalue-of method (where the technique for subclassing a method is wellknown in the art). References to values are then intercepted during thestyle sheet application process (FIG. 7B), and these intercepted valuesare passed through to the policies instantiated in Block 710. Theencryption attributes and techniques defined in the present inventionmay be used in addition to, or instead of, the attributes and techniquesdefined for policy objects in the referenced invention whereby the valueof an element could be altered (e.g. by changing numeric values to text,suppressing elements and values, etc.) during style sheet processing.(Note that it may be desirable to create an audit log during thisprocessing, to reflect the original data values encountered as well asthe data resulting from such value alterations. Techniques for creatingaudit logs are well known in the art, and do not form part of thepresent invention.)

Each policy object used by the preferred embodiments of the presentinvention preferably includes a method or attribute that specifies theminimum security strength required for encrypting the document elementswith which this object is to be used, and the members of the communityauthorized to view (i.e. decrypt) the value of this document element.The programmer creating the policy object code is responsible forspecifying this strength and community information. The community may bespecified statically, by including a list of the DNs of its members whocan be determined in advance, and/or executable code may be written inthe policy object to determine one or more DNs of community membersdynamically. When a group is to be specified as a community member, theprogrammer will preferably specify a DN of the group (if one isavailable); otherwise, the DN of each member may be (statically)specified, although this latter approach results in more time-consumingexecution during the encryption and decryption processes, and does notrespond to additions or changes in group membership unless thestatically-specified list in the policy object is updated. Or, code maybe written in the policy object to dynamically locate and return the DNsof each member of a particular group.

Block 715 asks whether this policy object specifies encryption of itsassociated data elements. This may determined by invoking a method thatreturns an attribute value specifying the minimum encryption strengthrequired, where a null value indicates that encryption is not requiredand a non-null value indicates that encryption is to be used.Alternatively, a method may be invoked which returns a Boolean attributevalue which has been set specifically (that is, without regard to theencryption strength attribute) to indicate whether encryption isrequired. If the test at Block 715 has a negative result, controltransfers to Block 720 to see if this was the last element definition.If it was, then the processing of FIG. 7A ends, and control continues tothe processing of FIG. 7B. If this was not the last element definition,control returns to Block 705 to read and begin processing the nextelement definition.

Control reaches Block 725 when the test in Block 715 has a positiveresult. Block 725 retrieves the community information associated withthis policy object, preferably by invoking a method such as“communityMembers” which returns a list of distinguished names. In theemployee record example used in FIGS. 3 and 4, the policy object for the“empl_mgr_hr” policy may use statically specified DNs for the managerand HR groups, but must include executable code to dynamically determinethe DN for the particular user whose information is represented indocument 400. The static DNs may be specified within the stored policyobject in a format such as:

-   -   DN=“cn=managers,ou=groups,o=acme” for the manager group, and    -   DN=“cn=hr,ou=groups,o=acme” for the HR group.        A DN for an individual user (such as a systems administrator)        may also be statically specified, using a syntax such as:    -   DN=“cn=admin,ou=users,o=acme”        By inspection of the syntax of these examples, it can be seen        that the distinguished names are structured with an organization        entry for Acme company (“o=acme”) at the root level, where the        root level is further divided into “users” and “groups” at the        organizational unit (“ou”) level, and where the “groups” level        is then further divided to have entries for “managers” and “hr”        at the common name (“cn”) level. The DNs for a group such as the        managers group and HR group may be used to retrieve DNs for each        member of those groups using techniques which are well known in        the art and do not form part of the present invention. Using        this same format, the DN for the medical department used in the        “empl_medical” policy object may be specified within the stored        policy object as:    -   DN=“cn=medical,ou=groups,o=acme”        where the “groups” level also has an entry for a group denoted        as “medical”.

A DN for an individual user that is dynamically retrieved has a similarsyntax to that used for statically specified DNs. Depending on how theregistry of DNs is organized, the user's DN in the employee recordexample may be located using his name and serial number, or perhaps justhis serial number, etc. The executable code in the policy object musttherefore scan the source document 400 (or other information source suchas a request header with which the source document was requested, asappropriate) to locate the value(s) to be used (such as searching forthe values of the “empl_name” 402 and/or “ser_nbr” 404 tags).

Block 730 compares the list of distinguished names for all members ofthis community to the lists of DNs of community members in the existingpreprocessing key class objects (where each DN 501 is contained in a keyobject 500 within a key class object 530, this key class object 530being represented at field 522 of each preprocessing key class object520).

If a preprocessing key class object 520 is not found which alreadycontains this community (a “No” result at Block 735), then a newpreprocessing key class object is created (Block 740). The encryptionstrength field 521 of object 520 is set to the value of the minimumstrength attribute of the policy object retrieved in Block 710. Theunencrypted key value 523 is preferably set to a null value, indicatingthat it has not yet been initialized. A key class object 530 is thencreated, and used as the value of field 522. The identifier 531 to beused for the key class is preferably generated as asequentially-increasing numeric value. Fields 532, 533, 534 arepreferably set to null values at this point: the actual values will bedetermined during the post-processing phase. A key object 535, 536, . .. 539 is then added to key class object 530 for each community member.Preferably, the DN for each community member will be used to searchalready-created key objects 500. If a match is located, the existing keyobject 500 (having the community member's DN in field 501, the communitymember's X.509 certificate in field 502, and a null value in field 503)will be used in the key class object 530. Otherwise, when a matching keyobject does not already exist, one must be created. The DN for themember will be used to retrieve the member's X.509 certificate. The newkey object 500 will be created by setting field 501 to the member's DN,field 502 a to the retrieved certificate, and field 503 to a null value.

Upon reaching Block 745, either a new preprocessing key class has beencreated for the community, or an existing preprocessing key class forthe community has been located. Block 745 then associates thispreprocessing key class object 520 with the policy object retrieved inBlock 710. Block 750 replaces the encryption strength field 521 with themost restrictive of (1) the minimum required strength from the policyobject and (2) the existing value of field 521 (referred to in Block 750as the element's strength and the class's encryption strength,respectively). Encryption strengths may be represented as numericvalues, where a higher number indicates a stronger encryption strength.In this case, Block 750 chooses the larger of the two numbers. Thepreprocessing key class object now contains the encryption strengthneeded by the element of class 531 that has the strongest encryptionrequirement. (This may result in over-encryption of some elements, whichis acceptable.) Control then transfers to Block 720, to determinewhether there are more element definitions to be processed.

The processing of FIG. 7B begins upon completion of the processing ofFIG. 7A. This processing may occur as part of the augmented XSLprocessor of the present invention, or may be performed by a transcodingproxy of the prior art (see description of a transcoding proxy 615 inthe discussion of FIG. 6, above). Block 752 applies a style sheet ruleto the source document 400. When the pattern of a style sheet rulematches an element of the source document, Block 754 asks whether thistemplate calls the existing XSL value-of method. If not, processing ofthe rule continues according to the prior art, and control transfers toBlock 759. According to the present invention, the value-of method ispreferably invoked for each element in the source document, in order toapply selective encryption to each element as needed. This may beaccomplished by applying a style sheet that copies all input values toan output document being generated. When the value-of method is invokedby the template rule, Block 756 retrieves (i.e. obtains a pointer orreference to) the previously-instantiated data policy object for thedata element which has matched the template rule. The overridingvalue-of method of this data policy object is executed at Block 758,performing any appropriate transformations that have been coded withinthis method. According to the present invention, the code of theoverridden value-of method is written to determine whether the policyobject specifies that the data element is to be encrypted (as describedabove with reference to Block 715), and if so, to insert encryptionmarkup tags around the element. The encryption markup tags preferablyuse a syntax such as as “<encrypt:data class=“n”>” and “</encrypt:data>”(as illustrated in FIG. 4B at 422 and 424), where the value of “n” isset to the identifier of the key class object that was associated withthis policy object in Block 745 of FIG. 7A. This process of applyingstyle sheet rules to mark up the source document 400 is repeated byiterating Blocks 752 through 759 until the source document has beencompletely processed (i.e. until the test at Block 759 has a positiveresult), after which the processing of FIG. 7B ends.

FIG. 4B illustrates an example of the result of comprising theprocessing of FIG. 7B upon source document 400. Note that the content420 of FIG. 4B represents interim information which is created and usedinternally. The information is never exposed in this form (See FIG. 4Cfor an illustration of the information that is exposed externally.)Markup tags 422 and 424 have been inserted to bracket thesecurity-sensitive values of the curr_salary and medical_conditiondocument elements. A first key class is to be used for encryption of thecurr_salary value, and a second key class is to be used for themedical_condition value, as indicated in the markup tags at 423 and 425,respectively. FIG. 4B further illustrates the organization of these keyclass objects. As shown at 430, key class “1” has an associatedalgorithm (shown in the figure as type=3DES”) and key length (shown inthe figure as len=“168”), and includes key objects 431, 432, 433 for thethree members of the associated community. Key class “2” is similar,using a different algorithm and key length (see 440), and specifying keyobjects 441, 442 for two community members.

Note that the “tempkey” elements 434, 444 of FIG. 4B depict examples ofthe unencrypted symmetric key 523 that will be used to create adifferent encrypted symmetric key 503 (shown in FIG. 4B and 4C as thevalues of the “Ekey” attribute) for each community member of theassociated key class. Note also that the KeyIdentifier values and theseEkey values depicted in the key classes (in both FIGS. 4B and FIG. 4C)are merely to allow visual representation. In an actual implementation,this information is preferably encoded as binary values using “base 64”rules as known in the art, such that the result contains only printablecharacters that are allowed in the context of the XML attribute values.

FIG. 7C depicts the post processing phase of the selective encryptionprocess. This logic is invoked upon completion of the processing of FIG.7B. The object of the post processing phase is to replace certain DOMelements with encrypted elements, and to insert the key objectsnecessary for decryption into the DOM root. FIG. 4B represents, withoutDOM tree structure, the interim document format 420 upon which the postprocessing phase operates.

As indicated in Block 760, the DOM tree corresponding to the documentbeing encrypted is scanned in a predetermined order. According to thepreferred embodiments, this order is defined to be the standard sequencefor sending the DOM in an output stream. Having a predetermined order isrequired for the preferred embodiments, which use cipher block chainingin which the output of each block encryption serves as key material forthe next block encryption. (If the order of scanning the DOM were variedrather than using a predetermined order, the receiver would be unable todecrypt the data as it would be unable to construct the interim keys.)Cipher block chaining (CBC) mode is preferred for use in the presentinvention over a non-chained mode to foil certain kinds of cryptographicattacks. Likewise, CBC is preferred over a stream cipher, to disguisethe length of the encrypted fields, so as to thwart other types ofcryptographic attacks. However, an alternative cipher mode such as ablock cipher or stream cipher, performed on a per-element basis, may beused without deviating from the inventive concepts of the presentinvention.

Block 765 checks the element tag which has been parsed by Block 760 todetermine whether this tag was marked (by Block 758 of FIG. 7B) asrequiring encryption. If not, then control transfers to Block 798,bypassing the encryption process of Blocks 770 through 795. Otherwise,when the element tag indicates that the element is to be encrypted,processing continues to Block 770. Block 770 reads the key class fromthe element tag, such as the value “1” specified at 423 in theencryption tag 422 of FIG. 4B. Block 770 then checks to see if this isthe first element to be processed for this key class. One way in whichthis determination can be made is to inspect the symmetric key value 523of the preprocessing key class 520 in which the identifier 531 of thecurrent key class is located (within field 522). If the symmetric keyvalue 523 is null, then this key class has not yet been processed, andBlock 770 has a positive result. Many alternative techniques may also beused, such as maintaining a lookup table of the key class identifiersfor those key classes which have already been countered.

Blocks 775, 780, and 785 perform setup operations for each new key classbeing processed. Block 775 initializes the encryption process for thiskey class. This initialization begins by resolving the requiredencryption strength 521 from the respective preprocessing key classobject 520 into a specific algorithm and key length (if this informationwas not directly specified in the policy object). Preferably thisresolution is done by consulting an LDAP directory as taught bypreviously-referenced (Ser. No. 09/240,387), but the exact means ofdetermining an algorithm and key length to provide a particularencryption strength is material to this invention. The resolvedalgorithm and key length are stored in the key class at 532 and 533,respectively. Next, a random symmetric key of the determined length isgenerated and inserted as the value of field 523 of preprocessing keyclass object 520. (Note that the post processing phase of the presentinvention does not expose this random symmetric key in clear text toother processes.) Furthermore, this random symmetric key 523 is thenused to initialize (see Block 790) the first iteration of the cipherblock chain for this key class, using techniques which are well known inthe art. This process may also involve inserting a string of randombits, called an a on vector, before the first bit of the data to beenciphered.

Block 780 encrypts the generated symmetric key 523 separately for eachcommunity member (that is, for each distinct DN within the community)authorized to view the associated document element. This is performed byaccessing each key object 500 (as stored in field 535, 536, . . . 539 ofkey class object 530) defined for the current preprocessing key class,and for each key object, (1) retrieving the public key 505 from theX.509 certificate 502 a, (2) using this public key 505 to encrypt thesymmetric key 523 using the encryption algorithm and key length storedat 532 and 533, respectively, and (3) storing the resulting encryptedkey in field 503 of the key object. This will result in one encryptedcopy of the symmetric key per community member having a separate DN 501and X.509 certificate 502 a. (In other words, when a community member isa group representing multiple individuals, then one encrypted copy ofthe plaintext symmetric key 523 is generated for the entire group and isassociated with the group's DN.) To save space, the preferredembodiments then replace the X.509 certificate 502 a with itscorresponding KeyIdentifier 502 b (such that format 500 is replaced withformat 510), which in combination with the distinguished name 501 allowsidentification of the specific certificate which was used duringencryption.

Block 785 then inserts the key class object 530 into the root of theDOM, as illustrated by the presence of key class objects 461, 462 inwhat may be considered the root area 460 of the output document 450 ofFIG. 4C.

At Block 790, the element value read by Block 760 is encrypted using theplaintext symmetric key 523 (e.g. having a value similar to that shownfor “tempkey” 434 in FIG. 4B), the encryption algorithm as identified by532, and the key length 533 for the element's key class 531. If this isthe first element being encrypted using a given key class, theinitialization vector created in Block 775 will be used as input to theencryption algorithm; otherwise, material resulting from the previousCBC operation for this particular key class is used.

Note that it may happen that an element to be encrypted has otherelements nested within it (i.e. as child elements) which also have apolicy specifying encryption. To handle this situation, the postprocessor preferably scans the entire subtree it is about to encrypt, todetermine if such nested elements exist. If so, the post processor thenpreferably determines the most restrictive type of encryption thatapplies to all elements of the subtree. The enclosing tags of theencrypted subtree represent the key class associated with thishighest-level encryption strength, and any encryption tags that havebeen inserted around nested elements are removed. The entire subtree isthen encrypted using this highest-level approach. Responsibility fallson the policy administrator who defines the security policies to ensurethat this type of processing will not result in encrypting for the wrongcommunity, or encrypting the subtree using the wrong algorithm. As willbe obvious, the policy administrator must understand the semantics ofthe data to be processed in order to properly assign the elementvisibility.

While the selectively-encrypted document example shown in FIG. 4Cdepicts the element tags as having been left unencrypted, it may happenin a particular situation that it is desirable to encrypt the tagsthemselves as well as the data value(s) enclosed by the tags. Toaccommodate this possibility, the associated policy object may bewritten such that it places the encryption tags (see 422, 424 of FIG.4B) surrounding the element tags rather than surrounding the elementvalue.

It is possible that an element to be encrypted may be shorter than, orequal to, or longer than the block length used in the CBC process. Ifthe data to be encrypted exceeds the block length, this step of thealgorithm creates multiple blocks. If the data to be encrypted (plus theinitialization vector) is not an even multiple of the block size,non-significant padding bits may be added at the end of the element,resulting in the last block for any given element containing zero ormore padding bits. Normally a CBC has padding bits only at the end ofthe last block of data. However, in the present invention because eachelement is encrypted in a separate operation, padding bits may bepresent at the end of the last block for each encrypted element.Alternatively, well-known methods such as ciphertext stealing may beused to create a final ciphertext block that is shorter than the blocklength.

The encrypted element is then tagged to indicate that it has beenencrypted (Block 795), using a syntax such as has been previouslydescribed (see 452, 454 of FIG. 4C) where the key class identifier 531is included as an attribute of the tag for use in a subsequentdecryption process. If the element contains padding bits, the number ofpadding bits may be indicated via an attribute on the encrypted element,or by preceding the plaintext data with a length field prior toencryption. (Note that this particular key class is necessarily one ofthe key classes such as 461, 462 in the document's DOM root, having beeninserted therein by Block 785.) The key class information from the DOMroot is required for the decryption process. Further note that when thedocument (such as document 450 of FIG. 4C) being generated is an XMLdocument, the new objects and their associated tags (such as the keyclasses 461, 462, the encrypted data tags 452, 454, etc.) which will betransmitted in this document according to the present invention appearas elements of the data policy name space (e.g. by using “encrypt:class”rather than simply “class” for key class objects 461, 462) in order toprevent ambiguous interpretation or unintended processing of theseobjects and tags.

Block 798 then checks to see if the end of the DOM stream has beenreached. If so, then the selective encryption process is complete, andthe output document 450 is ready for secure storing or securetransmission, and FIG. 7C ends. Otherwise, control returns to Block 760to read the next element from the DOM stream.

A number of different preferred embodiments are defined herein fordecrypting the selectively-encrypted document created by the processingof FIGS. 7A through 7C. As has been stated, each decryption processpreferably operates as part of an augmented XML processor. Eachpreferred decryption embodiment will now be described in turn.

First Preferred Embodiment for Decryption

In one preferred embodiment, an individual user (equivalently, a singleapplication program or process having its own DN) receives the encrypteddocument on his client workstation, and executes a decryption process onthat workstation. The logic with which this preferred embodiment may beimplemented in depicted in FIGS. 8A and 8B. (This preferred embodimentignores the case where a user may be an authorized community member byvirtue of being a member of a group, where that group is defined as acommunity member. The logic used to process a user as a group member isdiscussed below, with reference to FIGS. 10A-10C. Although thisembodiment discusses the processing of document receipt for anindividual who is not a group member as being separate from the logicfrom used to process a group member, it will be obvious to one of skillin the art that the logic for these cases can be combined in aparticular implementation. In particular, logic—such as that describedbelow beginning at Block 1006—may be inserted following a negativeresult in Block 825, also discussed below, to determine whether the useris a group member.)

At Block 800, the user has received a document (such as the documentrepresented at 450 of FIG. 4C) which has been selectively encrypted.This document may have been received in response to a request by thisuser. Or, it may have been forwarded to this user by another user orprocess, as part of a group collaboration effort. Provided that thisuser's public key was used to encrypt at least one of the encryptedelements of the document, the user will be able to access thatsecurity-sensitive information, regardless of whether the document wasoriginally created for this user. Block 805 reads a key class object(such as key class object 461 or 462) from the DOM root of the receiveddocument (where the augmented XML processor has created a DOM treerepresentation of the received document). If no such key classes exist,then this received document has not been selectively encrypted using thepresent invention, and the document may be rendered using processesoutside the scope of the present invention. Block 810 checks to see ifthis user's DN appears in one of the key objects for this key class. Inthe employee record example, assuming an employee's DN uses his serialnumber for the value of the CN field, the employee named John Q. Smithand having serial number E 135246 (see 402, 404 of FIG. 4A) would locatehis DN at key object 465, and thus Block 810 would have a positiveresult.

When Block 810 has a positive result, processing continues at Block 815where the encrypted symmetric key is retrieved from this key objectwhich has a DN matching the user's DN. (Referring to FIG. 5A, theencrypted key 503 is being retrieved from an object having the formatdepicted at 510.) The user's private key is then used to decrypt thisencrypted symmetric key at Block 820. Recall that the user's public keywas used to encrypt this key at Block 790 of FIG. 7C, and thus if thisuser is the proper holder of the public and private key pair, thedecryption process will succeed; otherwise, if the user does not holdthe private key corresponding to the public key used at Block 790, thenthis user will be prevented from accessing the security-sensitiveelements within the key class being processed.

Block 825 is reached following completion of Block 820, and following anegative result at Block 810. Block 825 checks to see if there are anymore key class objects in the DOM root of the received document. Theuser may be authorized for decrypting more than one key class, as in thecase of the employee in the employee record example where the employeeis to have access to all encrypted information (and will thus be set upas an authorized community member for every key class used to encryptthe document). If Block 825 has a positive result, then control returnsto Block 805 to process the next key class object; otherwise, all keysfor which this user is authorized have been recovered, and the encrypteddocument will now be processed.

Block 830 reads an element of the DOM, proceeding in the same streamorder as was used in the encryption process in order to reverse (i.e.decrypt) the cipher block chaining operations. Block 835 asks whetherthe element just read is encrypted, as determined by the presence of anencryption tag such as the tag in 452 of FIG. 4C. If not, then Block 840adds the plaintext element to an output buffer being created. Block 845checks to see if the end of the DOM stream has been reached. If not,control returns to Block 830 to process the next document element. If,on the other hand, Block 845 has a positive result (i.e. the documenthas been completely processed including decryption of those encryptedelements for which the user possessed the required private key), thecontents of the output buffer are used to render the document elementsfrom the output buffer (Block 850) using techniques which are known inthe art. The processing of FIG. 8A then ends.

Returning to Block 835, if this test has a positive result (i.e. theelement is encrypted), then an attempt will be made to decrypt theelement value using the logic shown in FIG. 8B. First, the key classidentifier is retrieved from the key class attribute (Block 855). Then,Block 860 checks to see whether this user recovered a symmetric key forthat retrieved key class. If so, then Block 865 asks whether this is thefirst element decrypted in this key class. If this test has a positiveresult, Block 870 indicates that the initialization vector that wasinserted according to the CBC of the prior art is discarded. If thistest has a negative result, then the results of the previous decryptionfor that key class are used to initialize the decryption algorithm.Block 875 then uses the key which was decrypted at Block 820 for thatkey class, along with the cipher block chaining input, to decrypt theencrypted element. Processing returns to Block 840 of FIG. 8A, where thedecrypted value is appended to the output buffer. If the user did notrecover a key for this key class, however, then Block 880 indicates thata substitute value may be used, such as “Element cannot be decrypted”.Control returns to Block 840 of FIG. 8A, where this substitute value isappended to the output buffer.

This approach of supplying substitute text (see Block 880) is used inthe preferred embodiments rather than returning garbled information tobe rendered to the user, or passing unintelligible (i.e. stillencrypted) data to an application program. Other techniques forproviding substitute text may also be used. For example, the encryptionstrength (e.g. “Classified”, “Top Secret”, etc.) associated with theelement may be indicated in place of the value which could not bedeciphered. Or, an indication could be provided visually to indicatethat the element was “censored” using an appropriate visual indication,or the encrypted value might simply be passed through for possibledecryption by another processing entity. Alternatively, it may bedesirable in a particular implementation to simply omit all reference tothe element from the output document. However, use of this substitutionapproach or any particular representation thereof is an optional featureof the present invention, and may be omitted without deviating from thescope of the present invention.

Second Preferred Embodiment for Decryption

Another preferred embodiment is defined for the situation where either(1) a user's workstation has insufficient processing power to performthe decryption process of the present invention, or (2) it is desired toavoid program code changes on the client workstation. Thus, a clientproxy performs the decryption process on behalf of the user (or onbehalf of an application executing on the user's workstation). The logicwith which this preferred embodiment may be implemented is depicted inFIGS. 9A and 9B. The user in this scenario uses a standard Web browserclient application (such as browser client 675 of FIG. 6) executing onhis workstation or a standard program client (such as program client680), and requests a selectively-encrypted XML document from a proxy(such as client proxy 655) acting on behalf of the browser client.Through use of this client proxy 655, this preferred embodiment enablesserving selectively-encrypted document content to browser clients 675 orprogram clients 680 without requiring any program changes or additionalsoftware operating on the client device.

FIG. 9A depicts the preferred embodiment of an initialization processperformed by client proxy 655 (referred to equivalently as a server) toenable the proxy 655 to access selectively-encrypted documents on behalfof a standard browser client 675 or a program client 680; FIG. 9B thenillustrates the preferred embodiment of the logic with which this proxydecrypts the content (if authorized to do so) and serves the decryptedcontent over a secure session (such as an SSL session) to that client.The description of FIGS. 9A and 9B will be in terms of the proxy 655acting on behalf of the browser client 675; however, it will be apparentto one skilled in the art that this logic applies also to a programclient 680. (The processing within the client is not depicted for thisembodiment, as the client processing uses techniques which are known inthe art: the novel functions whereby a selectively-encrypted document isserved according to the present invention operate on the client proxy inthis embodiment.)

First the user of browser 675 tries to access a specific Web page. Theserver 655, upon receiving this request at Block 900, ascertains browser675's capabilities (e.g. by inspecting the request header fields, as isknown in the art). At Block 902, if the browser 675 is capable of anappropriate level of encryption, an encrypted connection with mutualauthentication (referred to in FIGS. 9A and 9B as an SSL session forease of reference, although alternative protocols such as TLS may alsobe used) is established between the browser client and proxy. (Thepurpose of establishing a secure session between the browser and proxyis to enable the proxy to perform decryption of security-sensitiveinformation on behalf of the client, and then to return that decryptedinformation to the client using the secure session, thereby protectingthe decrypted information from exposure to other parties.) Otherwise, aconnection without SSL is established.

Block 904 tests whether a mutually-authenticated SSL session withencryption was established. If it was, processing continues at Block906; otherwise, processing continues at Block 922. At Block 906, theproxy 655 examines the client's certificate (which was passed during theSSL session establishment, according to the prior art). A number oftests may be performed on this client certificate using techniques whichare known in the art, such as: determining if it has expired;determining whether the chain of trust back to the root authority can bevalidated; etc. If the certificate is OK, at Block 908 server 655searches the LDAP directory 640 (or other repository) for the client'scertificate to obtain the associated DN. If the tests performed at Block906 indicate problems with the client's certificate (e.g. thecertificate is expired), control may optionally transfer to Block 920 toattempt to fix the certificate problem, as will be described below.(Alternatively, the server 655 may simply reject the client's requestsuch as by returning an error message when Block 906 has a negativeresult, after which the processing of FIGS. 9A ends. FIG. 9B will not beinvoked in this situation, as the client proxy is not able to serve asecure document to this requesting user.)

Block 910 checks to see if the corresponding DN was found. If so, theserver 655 may optionally perform the processing at Blocks 912 and 914.This optional processing comprises first testing at Block 912 to see ifthe certificate will expire soon (“soon” as may be defined by a systemsadministrator or installation policy, which information is accessible toserver 655, e.g., as policy information stored in a database or in anLDAP directory 640). If the certificate is expiring soon, this optionalprocessing continues at Block 914 where (assuming the user's certificatewas issued by a local certificate authority, and a reauthorizationrequest for this soon-to-expire certificate has not already been issued)the server 655 queues a reauthorization request (see 1270 of FIG. 12) tothe administrator application 630 but continues processing on behalf ofthe client 675. Finally, when either the optional processing of Blocks912 and 914 has completed or when this processing has been omitted, theserver 655 saves (Block 916) the user's DN with the SSL session contextfor future reference (see the description of Block 974, below). Block917 then checks to see if a URL for a selectively-encrypted document isalready available, e.g. from the client's request in Block 900. If so,then control transfers to Block 942 of FIG. 9B; otherwise, the server655 preferably builds a custom “https” Web page (i.e. a secure hypertexttransport protocol Web page to be transmitted over the secure session)for the user 675 at Block 918, such as a menu showing secure documentsthat user 675 may request. Alternatively, the server 655 may simplypresent a query menu such as a database front end to the user in Block918, allowing the user to search for particular selectively-encrypteddocuments which are available. After the processing of Block 918completes, control transfers to Block 940 of FIG. 9B to serve aselectively-encrypted page to the requesting user.

Returning now to the discussion of Block 904, if an SSL session was notestablished (e.g. the client 675 did not have a certificate), anoptional procedure may be performed whereby the server 655 attempts togather information for creating a client certificate. This optionalprocedure comprises Blocks 922 through 932, and begins with the serverdisplaying a registration form (Block 922) to solicit the entry ofnecessary identification data from the user. The user enters therequested information at Block 924 (for example, name, organization,telephone number, e-mail address, employee number, credit card number),which can later be independently verified by the administrator 630 inthe process that is described below with reference to FIG. 12. (It willbe understood that the specific registration identification data to becollected and validated will differ according to the needs of aparticular installation. Such organizational policies may be establishedand enforced through the use of an LDAP directory 640.) The server 655then assigns user 675 a distinguished name and certificate (Block 926).Note that at this time, the new certificate is not yet associated withany access privileges. It simply enables the user 675 to be uniquelyidentified as associated with the assigned DN on subsequent visits, byproving his relationship to the certificate associated with his DN usinga digital signature. At Block 928, the server 655 stores (e.g. in theLDAP directory 640) the user's data entry (from Block 924), DN, andcertificate for future reference.

At Block 930, the server 655 creates a “new user approval request” (see1290 of FIG. 12) using the registration information which has beenobtained, and places this request into the administrator's work queue(see 1200 of FIG. 12) for later processing. Finally, at the completionof this optional processing, a default secure Web page may be displayed(Block 932) to the new user, where this default page may display amessage such as “Welcome to the secure document server system. You willbe contacted by e-mail when your access privileges have been granted.”The processing of FIG. 9A (and also FIG. 9B, as the client proxy cannotyet decrypt a secure document on behalf of this user) is then complete.

Returning now to the discussion of Block 906, if a secure session wasestablished, but problems were found with the client's certificate, thena further optional feature of this preferred embodiment may be performedby transferring control to Block 920 from Block 906. Block 920 checks tosee if any previous registration data exists for this client (e.g. inLDAP directory 640). If not, then the optional processing previouslydescribed for Blocks 922 through 932 may be performed (or, processingmay simply end). If previously-existing data is found, then according tothis optional feature the server 655 may proceed by creating areauthorization request that will use this existing information, andcontrol transfers to Block 930 (discussed above) to queue this requestfor processing.

The optional feature just described with reference to Block 920 may also(optionally) be invoked from Block 910, when the search for the client'sDN does not complete successfully. When Block 910 has a negative result,it is known that the client had a valid certificate (a “Yes” result atBlock 906), but that no DN matching this certificate was found in theLDAP directory 640 or other repository which was searched at Block 908.

It is well known in the art that proliferation of digital certificatesis becoming a problem, causing confusion among users and eventuallyleading to scalability problems due to the number of certificatesrequired to be stored, accessed, renewed, etc. for each client. Thus,the optional processing of Block 920 which attempts to locate and usepreviously-existing registration information may be provided in animplementation of this preferred embodiment with the goal of enabling auser with an existing valid certificate (or one that may have expired,and merely needs to be renewed, as is the case when this processing isinvoked in response to a negative result at Block 906) to be added tothis secure document system without necessarily issuing the user a newcertificate. Therefore, when this optional processing locates existingregistration information (a “Yes” result at Block 920), this existinginformation is used to prepare a work request for the administrator (asdescribed above with reference to Block 930), requesting the creation ofa new entity (see 1290 of FIG. 12).

FIG. 9B depicts the processing with which the client proxy 655 decryptsand serves a selectively-encrypted document to a client 675, after theprocessing of FIG. 9A has been performed. The user 675 chooses aselectively-encrypted document at Block 940 (e.g. such as from the menudisplayed in Block 918). The server then retrieves this requesteddocument (Block 942). (Note that control also reaches Block 942following a positive result at Block 917 of FIG. 9A.) The augmented XMLpreparser 660 operating on the server 655 now reads the DOMrepresentation of the document (Block 944) in stream order (to alignwith the order in which the document was parsed during encryption) foran element encrypted according to the present invention. If the elementlocated at Block 944 is not encrypted (a “No” result at Block 946), theserver proceeds to Block 966, where the plaintext data is appended to anoutput buffer. Otherwise, when the element is encrypted (a “Yes” resultat Block 946), the proxy 665 will attempt to decrypt this element onbehalf of the client 675.

The process of decrypting an element on behalf of the client 675 beginsat Block 948, where the proxy 665 expands the groups membership of thoseDNs which represent groups in the key class of this element. Referringto the example document in FIG. 4C, the processing of Block 948comprises locating the key class identifier 456 when processingencrypted element 452, then finding the DNs of groups 471, 473 from thekey objects within the key class 461 having the identifier 456 (sec 463)which is located on the encrypted element tag, and then determining themembership of these groups having common names “managers” 470 and “hr”472. When an LDAP directory is used for storing group membershipinformation, as has been described, determining the membership comprisesissuing an LDAP command for each DN assigned to a group, where thatcommand retrieves the DNs of the individual members of the group. (Aswill be obvious, when a data repository other than a directory is usedfor storing group membership information, the retrieval commandappropriate to that repository is used.) Alternatively, a query can beperformed in the form of “Is this (individual DN) a member of this(group DN)?”.

After expanding the groups in this key class, Block 950 asks whether theuser on whose behalf the proxy is operating is a member of any of thesegroups. If not, control transfers to Block 964 where a message ispreferably generated (rather than using the still-encrypted element, asdiscussed above with reference to Block 880) and appended (Block 966) toan output buffer, indicating that the element could not be decrypted.When the user is a member of at least one authorized group, processingcontinues at Block 960.

Block 960 locates the clerk for the group (or, if the user is a memberof multiple groups authorized for this key class, the clerk of any suchgroup), where the clerk is the holder of the private key for the group.When using an LDAP directory, this comprises querying the LDAP directoryusing the group DN for the group identified in the key object,requesting the DN for the group's clerk. If the group clerk is found(Block 962), then control transfers to Block 972; otherwise, the absenceof a group clerk dictates that the element cannot be decrypted on behalfof the group member, and a substitute element to this effect is appendedto the output buffer in Blocks 964 and 966.

At Block 972, the proxy preferably establishes a secure SSL (or othermutually-authenticated protocol) session to the group clerk. Block 974then requests the clerk to decrypt the encrypted symmetric key from thekey object establishing this user as an authorized community member.This request to the clerk comprises passing the key object containingthe encrypted symmetric key, the proxy server's certificate, and the DNof the user. (Note that the proxy should be contacted only once for aparticular key class for which a symmetric key is needed duringdecryption of a document.) Preferably, this information will bedigitally signed before passing it from the proxy to the clerk, such asby signing a message digest with the user's private key corresponding tothe user's X.509 certificate. Signing can prevent a man-in-the-middleattack or a replay attack. (Various signing methods known in the art maybe used without departing from the scope of the present invention.) Whena mutually-authenticated secure session (such as an SSL or TLS session)is being used between the proxy and clerk, digitally signing thetransmitted information is not strictly necessary, as the encryptedsession provides equivalent data integrity. In one aspect of thispreferred embodiment (further discussed with reference to Block 982,below), the element to be decrypted is also part of the signedinformation passed to the clerk. (Recall that the user's DN was savedduring the processing of Block 916.) Referring to the document 450 inFIG. 4C, suppose the user has been determined to be a member of the“managers” group 470, 471. In that case, the key object 464 is passed byBlock 974 to the clerk for the managers group, requesting the clerk todecrypt key 475.

Block 976 represents processing by the group clerk, where the clerkchecks to see if the user and proxy server are both members of theauthorized group. (Note that the proxy server should be an authorizedgroup member, as it will have access to the decrypted security-sensitiveinformation if the decryption process completes successfully.Furthermore, the proxy may be specified as a group member of acommunity, using a syntax similar to 470, 471 of FIG. 4C where the“managers” value 470 is replaced by a value such as “proxy” or“proxies”. If the clerk detects during Block 976 that this group syntaxhas been used to specify the proxy, then the proxy group must beexpanded—as described above for Block 948—to verify that the proxy isindeed an authorized community member.) When the information passed tothe clerk has been digitally signed (during the processing of Block974), the verification process performed in Block 976 by the clerkpreferably also comprises verifying the digital signature (usingtechniques which are well known in the art) to ensure that the requesteris the true source of the request, and that the information has not beenaltered since its signing—although this verification may be omitted ifthe information was received on a mutually-authenticated secure session.If Block 976 returns a negative result, an error code or other failureindicator is returned to the proxy by the clerk, indicating that theclerk will not decrypt an element for this proxy on behalf of this user.Control then transfers to Block 964, where a suitable text message isplaced into the output buffer.

If the test in Block 976 succeeds, the clerk then decrypts (Block 978)the symmetric key from the key object passed to it in Block 974. Theclerk maintains a private key for each group on whose behalf it performsa clerk function. Thus, the private key for the group identified in thekey object is used for this decryption process. Block 980 checks to seeif this decryption was successful. If not, error handling (as describedfor a “No” result in Block 976) is performed. When the decryptionsucceeds, the clerk has recovered the symmetric key used to encrypt alldocument elements referencing this particular key object (i.e. thedocument elements authorized for this group within this particular keyclass), and processing continues to Block 982.

In a first aspect of this preferred embodiment (where the elementlocated in Block 944 has not been passed to the clerk in Block 974),after the clerk decrypts the encrypted symmetric key (Block 978, above)using the group's private key, the clerk then re-encrypts thenow-plaintext key using the public key of the proxy (which can beobtained from the proxy certificate passed in Block 974). This newversion of the symmetric key is then digitally signed by the clerk usingthe clerk's private key, and returned to the proxy (not shown). Uponreceiving this re-encrypted signed key, the proxy verifies the clerk'sdigital signature, to ensure that the transmission was not sent from animposter clerk and has not been altered. The proxy then uses its ownprivate key to decrypt this re-encrypted key. At Block 982, thisdecrypted key is then used by the proxy to decrypt the element locatedby Block 944, and this element is then appended to the output buffer(Block 966). In this aspect, security of the sensitive information isfurther protected by having only one process (i.e. the proxy) accessingthe encrypted element value on the user's behalf rather than two (i.e.the proxy and the clerk, as will be described below for an alternativeaspect). Optionally, the clerk may also return the proxy's certificate(or the corresponding key identifier) when the newly-reencrypted key isbeing returned, so that the proxy can easily locate the correspondingprivate key on its local key ring or key chain (given that the proxy mayhave multiple certificates, and multiple private keys).

Note that in this first aspect, because the clerk encrypts the sensitiveinformation (the newly-encrypted symmetric key to be used for decryptingthe document element) it returns to the proxy, it is not strictlynecessary to have a mutually-authenticated secure session between theproxy and clerk. If, on the other hand, a mutually-authenticated securesession does exist between these parties, then the clerk may simplyreturn the key decrypted in Block 978 to the proxy over this securesession, rather than re-encrypting the key and returning thisre-encrypted version.

In an alternative aspect of this preferred embodiment, the element to bedecrypted has been passed to the clerk during the operation of Block974. The clerk uses the symmetric key which it decrypted at Block 978 todecrypt this document element at Block 982. The decrypted element maythen be returned (not shown) from the clerk to the proxy unencrypted,provided that a mutually-authenticated secure session exists betweenthem. (Otherwise, similar to the technique described above for the firstaspect of this embodiment, if a mutually-authenticated secure session isnot available, then the clerk must re-encrypt the decrypted documentelement with the proxy's public key, and sign the result with theclerk's private key, before returning the element to the proxy over thenon-secure session. Upon receiving this re-encrypted element, the proxyverifies the clerk's digital signature, to ensure that the transmissionwas not sent from an imposter clerk and has not been altered, and thenuses its own private key to decrypt the re-encrypted element.) Thereturned element is then appended to the output buffer (Block 966) bythe proxy. This type of optimized embodiment might be suitable for animplementation in which both the clerk and proxy functions reside on thesame computer.

After Block 966 has appended an element to the output buffer (whether itis a decrypted element, a plaintext version of an element that did notneed decrypting, or an error message indicating an element could not bedecrypted), Block 968 checks to see if the document being processedcontains any more elements. If so, control returns to Block 944 to,retrieve the next of these elements. Otherwise, Block 970 passes thenow-complete output buffer representing the document contents back tothe requesting user on the secure session, for local rendering on theuser's device or by the program client, and the processing of FIG. 9Bends. (Alternatively, control may return to Block 940 followingcompletion of Block 970, to await another selection by this user.)

It should be understood that the proxy 655 may also convert thedecrypted document into one or more other tagged formats as appropriatefor a particular client, such as HTML, Wireless Markup Language (“WML”),Standard Generalized Markup Language (“SGML”), or even the internal fileformat used by a word processor or printer before returning the documentcontent at Block 970.

Third Preferred Embodiment for Decryption

In yet another preferred embodiment, the encrypted document is requestedand received by a member of a group, where the group may be anauthorized member of a community which has access to at least oneelement of the selectively-encrypted document. The group member thenuses a clerk process to decrypt the symmetric key so the group membercan decrypt certain fields of the document. The logic with which thispreferred embodiment may be implemented is depicted in FIGS. 10A through10C.

The processing of FIG. 10A begins with a group member requesting aselectively-encrypted document from a document server at Block 1000 (forexample, by selecting a document identifier from a menu, by issuing adatabase query which results in selection and retrieval of the document,etc.) Block 1002 indicates that the group member (referred toequivalently as the “user” for the remainder of the description of FIGS.10A-10C) receives the requested document. The decryption process thenbegins. (Note that while the processing of document receipt for a groupmember and for an individual who is not a group member has been shown asseparate logic in FIGS. 10A-10C and FIGS. 8A and 8B, respectively, itwill be obvious to one of skill in the art that the logic for thesecases can be combined in a particular implementation. Similarly, thelogic for using a client proxy to decrypt a document on behalf of auser, as depicted in FIGS. 9A and 9B, may be combined with either orboth of these other approaches. Furthermore, the key recovery techniqueto be described below with reference to FIG. 11 may be combined with anycombination of the other functions.)

Block 1004 reads a key class (such as 461, 462 of FIG. 4C) from the rootof the DOM representation of the retrieved document. Any DNs in this keyclass which represent groups are expanded (e.g. by issuing LDAP queriesto retrieve the DNs of the group members, or other equivalent techniquewhen a different storage repository is used) at Block 1006. Block 1008checks to see if this user is a member of any of the expanded groups.(Alternatively, the user may consult locally-stored information todetermine if he believes himself to be a member of any of the groups.Such locally-stored information can result from the notification thatwill be described in reference to Blocks 1240 and 1287.) If so, then thekey class object is preferably added to a list of key class objects inBlock 1010, where the list of all key classes needing decryption iscreated for subsequent processing according to the logic of Blocks 1014through 1022, as will be described. This approach reduces the number ofsecure session establishments and network roundtrips if a given clerk isresponsible for more than one group. Alternatively, the logic of Blocks1014 through 1022 may be invoked immediately upon encountering apositive result in Block 1008, with the possibility of contacting aparticular clerk more than one time. (If a particular user is a memberof more than one group for any given key class, animplementation-specific decision may be made as to which group toprocess, i.e. which clerk to contact, and as to whether a failure tolocate the clerk and successfully decrypt the key objects for thatselected group should be followed by attempting the process for anysubsequent groups or alternate clerks for the same group, if any exist.)

Control reaches Block 1012 when the user is not a member of any expandedgroups (a “No” result at Block 1008), and also after the processing ofBlock 1010. Block 1012 checks to see if there are any more key classesin the DOM root. If so, control returns to Block 1004 to process thenext key class; otherwise, processing continues at Block 1014.

The processing depicted in Blocks 1014 through 1024 is repeated for eachdifferent clerk responsible for the key classes accumulated by Block1010. Block 1014 locates the clerk responsible for a group. A groupclerk must be contacted to decrypt the group's encrypted symmetric key(such as key 475 of FIG. 4C), as users who are group members do not havelocal access to the group's private key; instead, the group clerkmaintains this private key. Preferably, the group clerk is located byaccessing the information for the group in the LDAP directory (or otherrepository), where this information includes the identification of theclerk. Block 1016 asks whether the group clerk was found. If not, thenthe remaining logic of FIG. 10A is bypassed for this group (or groups,if multiple groups use the same clerk), and processing continues atBlock 1028 of FIG. 10B. (Any encrypted elements in key classes for whichthis logic bypassing occurs will not be able to be decrypted, as will bediscussed with reference to FIG. 10B.)

After locating a group clerk successfully, Block 1018 preferablyestablishes an SSL or other mutually-authenticated secure sessionbetween the user and the clerk. Preferably, the user then digitallysigns each key class object that will be transmitted to the clerk (Block1020). (As previously described with reference to Block 974 of FIG. 9B,it is not strictly necessary to digitally sign the key class objects ifthey are to be transmitted on a mutually-authenticated secure session.)The key class objects and the user's corresponding signing certificate(or its corresponding key identifier) are then passed to the clerk(Block 1022). (Note that if a mutually-authenticated secure session wasnot established, then the certificate of the user must be passed to theclerk; otherwise, the key identifier can be passed instead.) Theprocessing which occurs at the group clerk in response to receiving thisinformation is shown in FIG. 10C, and will now be discussed.

At Block 1060 of FIG. 10C, the clerk process has received one or morekey class objects which need to be decrypted for the user, along withthe user's certificate (or equivalently, the user's DN and keyidentifier). Each key class object is processed according to the logicof Blocks 1060 through 1070, after which the clerk is finished andawaits another such request. Block 1060 gets a key class object from thepassed information. If the objects have been digitally signed, the clerkpreferably verifies this digital signature. (As previously describedwith reference to Block 976 of FIG. 9B, the creation of digitalsignatures and verification thereof may be omitted if information isbeing transmitted on a mutually-authenticated secure session.) At Block1062, the clerk checks to make sure that the requester is an authorizedmember of the group whose DN appears in the key class object, byquerying the directory or other repository to determine the groupmembers. If the requester is not an authorized group member, controltransfers to Block 1068 without further processing of this key classobject. Otherwise, when Block 1062 has a positive result, the clerkdecrypts the group's encrypted symmetric key from the key class objectusing the clerk's local copy of the group's private key. (Recall thatthe group's public key was used to encrypt this field, according toBlock 780 of FIG. 7C.) The clerk then re-encrypts the result (Block1066), using the public key of the requester as determined from thecertificate which has been passed with the decryption request.(Alternatively, if a DN and key identifier were passed with thedecryption request instead of a certificate, the clerk will use the DNto obtain a list of certificates corresponding to this DN from an LDAPdirectory or other repository. The clerk will then select a particularcertificate from the returned certificates using the passed keyidentifier, and the public key from this particular certificate will beused in Block 1066.) The clerk may alternatively omit the re-encryptionof the result in Block 1066, provided that a mutually-authenticatedsecure session was established during Block 1018.

If there are more key class objects in this request (Block 1068), thenext key class is processed by returning control to Block 1060;otherwise, the key class object(s) and re-encrypted symmetric key(s)(or, depending on the alternative processing just described, one or moreplaintext keys and/or plaintext document elements, or re-encrypteddocument elements) are digitally signed by the clerk (if the sessionbetween the requester and clerk is not a mutually-authenticated securesession), and returned to the requester (Block 1070), after which theprocessing of FIG. 10C ends.

Returning now to FIG. 10A, Block 1024 resumes the user's processing,after the clerk processing of FIG. 10C has completed, by receiving thekey objects (i.e. within key class objects) which were passed.Optionally, the certificate which was passed (or its key identifier) mayalso be returned so that the requester can easily locate thecorresponding private key on its local key ring or chain (given that arequester may have more than one certificate and private key). If thereturned information was digitally signed by the clerk, the user firstverifies the digital signature to ensure that the information was notcreated by an impostor and has not been altered. (If the session betweenthe user and clerk is a mutually-authenticated secure session, then thesigning by the clerk, and verification by the user, is not required.)The user then decrypts the symmetric key from each key class objectreturned from a group clerk (Block 1026) using the user's private key.(Or, if the keys are returned unencrypted on a mutually-authenticatedsecure session, this decryption in Block 1026 is not required: theseunencrypted keys will be used directly for decrypting elements of theassociated key classes.) The user will now be able to decrypt theelements for that key class, as will now be described with reference toFIG. 10B.

The elements of the DOM are read in stream order (Block 1028), to matchthe order in which they were read and processed during encryption. Block1030 asks if the element just located is encrypted. If not, controltransfers to Block 1038 where the unencrypted element is appended to anoutput buffer being created. Otherwise, when the element is encrypted,Block 1032 checks to see if a decrypted symmetric key exists for the keyclass associated with this element. If there is no such decryptedsymmetric key (e.g. the user was not a member of any authorized groupsfor this element, or the group clerk could not be located, etc.), thenthis user is not authorized to view the encrypted element, and asuitable message is substituted for the encrypted element at Block 1034.When the symmetric key for this key class was successfully decrypted,Block 1032 has a positive result and Block 1036 uses that decrypted keyto decrypt the element. Block 1038 then appends the result to the outputbuffer. If there are still more elements to be processed (a “Yes” resultat Block 1040), processing returns to Block 1028; otherwise, the outputbuffer is complete and its contents are rendered for the user at Block1042. The processing of the encrypted document is now finished, and FIG.10B ends.

Fourth Preferred Embodiment for Decryption

It may become necessary to recover the entire contents of a document(for example, when an encrypted document stored in a company repositorybecomes the subject of litigation) without regard to how the documentwas broken down into different key classes during the encryptionprocess. Another preferred embodiment of the present invention defines atechnique whereby an authorized user (such as a systems administrator,escrow agent, etc.) may recover all the keys which were used to encryptsuch a document. The logic with which this key recovery technique may beperformed is shown in FIGS. 11A and 11B.

According to this preferred embodiment, the party which is to haveauthority for recovering all keys (hereinafter referred to as the “keyrecovery agent”) is defined as an authorized community member for eachkey class of each document. This will cause a key object for the keyrecovery agent to be included in the document for each key class, wherethe key object includes a symmetric key which has been encrypted withthe key recovery agent's public key. Thus, the key recovery agent'sprivate key can be used to decrypt the symmetric key if that becomesnecessary, providing access to the encrypted elements of the key class.

Note that this key recovery technique is also beneficial for othersituations, for example: the private key that would otherwise be used todecrypt a document element becomes lost; a user holding a private keyleaves the company without providing the private key value; a userholding a private key as a group member is reassigned, and is no longera group member; etc.

FIG. 11A depicts additional logic that may be inserted into the logicflow of FIG. 7A, above, for the encryption process. (Note that thisadditional logic is not strictly required if it can be determinedconclusively that the key recovery agent was included in the communityfor each stored policy object. Use of this additional logic, however,provides a technique to ensure that the key recovery agent will haveaccess to the elements in every key class.)

The logic of FIG. 11A modifies the flow of control from Block 725 ofFIG. 7A to Block 730 of FIG. 7A, and thus these substitute blocks arerepresented in FIG. 11A as Blocks 725′ through 730′, respectively.Following operation of Block 725′, Block 726 asks whether the keyrecovery agent is a member of the retrieved community. If not, thenBlock 727 adds the DN (or other similar identifier, when using a storagerepository other than an LDAP directory) for the key recovery agent.Thus, when the encrypted symmetric keys are later created (see Block 780of FIG. 7C), the key recovery agent's public key will be used in a keyobject having the agent's DN, and the agent will subsequently be able todecrypt this symmetric key (and its associated elements) using itsprivate key.

FIG. 11B shows how the logic flow of FIG. 8B may optionally be modifiedto account for the key recovery agent. Blocks 855′, 865′, 870′, and 875′of FIG. 1B represent the same functionality as Blocks 855, 865, 870, and875 of FIG. 8B. (Refer to the discussion of FIG. 8B, above, for adetailed description of this processing.) However, because the keyrecovery agent will always be an authorized community member, theexisting test at Block 860 of FIG. 8B will always have a positiveresult, and thus this test and Block 880 (which handles the negativeresult) may be omitted. As will be obvious, the modification shown inFIG. 11B should only be made if the implementation is tailoredspecifically to the key recovery agent.

Administration

FIG. 12 depicts the preferred embodiment of the logic with which anadministrator or administration process sets up and administers thesecure document system of the present invention. This logic begins atwork request queue 1200 where one of processes 1210, 1220, 1250, 1270,or 1290 is dispatched according to the type of work request.

In Block 1210 the administrator 630 creates a new group by 1215 puttingan entry for the group into the LDAP directory 640. Block 1219 indicatesthat no further processing is required for this type of work request.Note that after a group has been created, it is non-functional until atleast one clerk entity and at least one member entity are associatedwith the group. A group can have more than one clerk. It can have zeroor more authorized agents (proxies).

In Block 1220 the administrator 630 adds an entity to a group. In Block1225 a test is made to see if the group already exists in the LDAPdirectory 640 as a result of prior group creation 1210. If not, this isan error (Block 1245). In Block 1230 a test is made to see if the entityto be added already exists in the LDAP directory 640 (as a result ofprior entity creation 1290). If not, this is also an error (Block 1245).Passing both tests 1225 and 1230, the entity is added to the group inBlock 1235. Then optionally the entity is notified (Block 1240). Forexample, this might be an e-mail notice telling the user 675 to logon tothe secure document system because secure documents may now be accessed.Block 1249 indicates that no further processing is required for thistype of work request. Such notification may also enable an optimizedimplementation in which a group member decides locally that it shouldattempt to contact a clerk, without first retrieving apossibly-very-long list of all group members from an LDAP directory todetermine its own group membership.

In Block 1250 the administrator 630 removes an entity from a group. InBlock 1255 a test is made to see if the group already exists in the LDAPdirectory 640. If not, this is an error (Block 1245). In Block 1260 atest is made to see if the entity to be removed already exists in theLDAP directory 640. If not, this is also an error (Block 1245). Passingboth tests 1255 and 1260, the entity is removed from the group (Block1265). If the entity is a member of more than one group and the entityis to be completely removed from all such groups, then Block 1265 isrepeated for each such group. If the entity's certificate was not onecreated according to Block 1280, then the certificate revocation list(Block 1267) is updated, for example by making an entry in the LDAPdirectory and/or contacting the certificate authority 635. Block 1269indicates that no further processing is required for this type of workrequest.

In Block 1270 the administrator 630 reauthorizes an entity that iscurrently a member of a group, such as after receiving a reauthorizationrequest (see Block 914 of FIG. 9A). In Block 1275 a test is made to seeif the entity's access privileges or certificate have been revoked. Ifso, the process proceeds to Block 1278 whereupon a revoke entity workrequest (Block 1250) is processed via entry point 1205. If not, in Block1277 the administrator 630 examines the registration data provided bythe user 675 (in Block 924 of FIG. 9A). If the data is satisfactory, theadministrator 630 issues an updated certificate with a new expirationdate (Block 1280), updates the directory (Block 1285), and optionallynotifies the entity (Block 1287). Block 1289 indicates that no furtherprocessing is required for this type of work request. If theregistration data (a “No” result in Block 1277) is not OK, the processproceeds to Block 1278 whereupon a revoke entity work request (Block1250) is processed.

In Block 1290 the administrator 630 processes a request to create a newentity 655, 670, 675, or 680. First the administrator 630 examines theregistration data (from Block 924 of FIG. 9A) at Block 1292. At Block1294 if the data is satisfactory, the administrator 630 issues a newcertificate, if needed, in a manner similar to Blocks 1280-1287,otherwise uses the entity's existing certificate, determines (Block1298) what group(s) the entity should be added to, processes these groupadditions such as by creating multiple work requests (Block 1300) andqueuing these as input to Block 1200, and then branching to Block 1202multiple times to process these queued requests. Block 1309 indicatesthat no further processing is required for this type of work request.

Thus, at the conclusion of the administration processing in Block1220-1249 and their necessary antecedents, a client 675 is able toperform the logic of Blocks 902-918 of FIG. 9A (establishing an SSLsession to the secure document server 655), and perform the logic ofFIG. 9B to select an encrypted document, get it decrypted, and securelyview the elements of the document for which the user 675 is authorized.

As has been demonstrated, the preferred embodiment of the presentinvention provides an easy-to-use, flexible approach for enforcingsecurity policy. The security policy information may be different fromone data element to another, and is specified by binding the data policyidentifier (i.e. the URI where the policy is stored) to the data elementin the document DTD. The present invention is backward compatible,permitting XML documents to be used by both XSL processors which havebeen modified to utilize policy instrumentation according to the presentinvention, as well as by XSL processors which have not been so modified.(Such unmodified XSL processors simply perform the entity substitutionof the data policy URIs within the DTD, but do not retrieve nor processthe policy objects referred to by those URIs.)

A further advantage of the present invention is that no change isrequired in the style sheet that controls the transformation. The stylesheet references to the value-of method remain unchanged. The presentinvention enforces security policy by overriding the code that isinvoked upon encountering a value-of method invocation from the(unmodified) style sheet. (It would be possible, of course, to modify astyle sheet to take advantage of the policy mark-up of the XML documentif desired.)

The present invention is neutral to the format of the security policyitself what is required for enforcing a security policy is only that thepolicy can be accessed by a URI (such as the references to policyobjects in an LDAP directory, as shown in FIG. 3) and, of course, thatthe policy is understood by the instrumentation enforcing that policy inthe XSL processor. This has the additional benefit of longevity insolution implementation, since the implementation of the preferredembodiment will not need to be adjusted as new enterprise securitypolicy requirements force a change in the policy encoding andinstrumentation: the stored policies will then simply be updated toenforce the new policy requirements, and the references to the storedpolicy may be updated as necessary (e.g. if the updated policy is storedin a different location).

Although the preferred embodiment has been described as using XSL stylesheets, style sheets in other notations may be used instead of XSL (e.g.Document Style Semantics and Specification Language, or DSSSL, which isan International Standard ISO/IEC 10179: 1996) without deviating fromthe inventive concepts of the present invention. In addition, thepolicy-driven XSL processor described can also be used to generateencrypted documents in non-XML formats that use SGML-derived tagging,such as HTML; however, a decoder for such a format would need to bemodified using the logic defined herein for the augmented XML processorso that the document could be decrypted. This process, however, may notyield a usable document if the viewer is not allowed to see all thedocument data, due to assumed relationship rules in the non-XML languagetags.

While the preferred embodiment of the present invention has beendescribed, additional variations and modifications in that embodimentmay occur to those skilled in the art once they learn of the basicinventive concepts. Therefore, it is intended that the appended claimsshall be construed to include both the preferred embodiment and all suchvariations and modifications as fall within the spirit and scope of theinvention.

1. A computer program product embodied on computer readable mediareadable by a computing system in a computing environment, for enforcingsecurity policy using style sheet processing, comprising:computer-readable program code for obtaining an input document;computer-readable program code for obtaining a Document Type Definition(DTD) that defines elements of said input document, wherein: (1) anattribute of at least one element defined in said DTD references one ofa plurality of stored policy enforcement objects; (2) more than one ofsaid references may reference a single stored policy enforcement object;and (3) each of said stored policy enforcement objects specifies avisibility policy for said referencing element or elements, saidvisibility policy identifying an encryption requirement for all elementshaving that visibility policy and a community whose members areauthorized to view those elements; computer-readable program code forapplying one or more style sheets to said input document, thereby addingmarkup notation to each element of said input document for which saidelement definition in said DTD references one of said stored policyenforcement objects specifying a visibility policy with a non-nullencryption requirement, resulting in creation of an interim transientdocument that indicates elements of said input document which are to beencrypted; and computer-readable program code for creating an outputdocument in which each element of said interim transient document forwhich markup notation has been added is encrypted in a manner thatenables each community member that is authorized to view that element touse key distribution material associated with the output document todecrypt the encrypted element, and that precludes decryption of theencrypted element by unauthorized community members.
 2. The computerprogram product according to claim 1, wherein said markup notation insaid interim transient document comprises tags of a markup language. 3.The computer program product according to claim 1, wherein said inputdocument is specified in an Extensible Markup Language (XML) notation.4. The computer program product according to claim 3, wherein saidoutput document is specified in said XML notation.
 5. The computerprogram product according to claim 1, wherein said stored policyenforcement objects further comprise computer-readable program code foroverriding a method for evaluating said elements of said input document,and wherein said computer-readable program code for applying said one ormore style sheets further comprises computer program code for invokingsaid computer-readable program code for overriding, thereby causing saidmarkup notation to be added.
 6. The computer program product accordingto claim 5, wherein said style sheets are specified in an ExtensibleStylesheet Language (XSL) notation.
 7. The computer program productaccording to claim 6, wherein said method is a value-of method of saidXSL notation, and wherein said computer-readable program code foroverriding said value-of method is by subclassing said value-of method.8. The computer program product according to claim 5, wherein: saidoverriding method comprises: computer-readable program code forgenerating said markup notation as encryption tags; andcomputer-readable program code for inserting said generated encryptiontags into said interim transient document to surround elements of saidinterim transient document for which said visibility policy of saidelements in said input document have said non-null encryptionrequirement; and said computer-readable program code for creating saidoutput document further comprises computer-readable program code forencrypting those elements surrounded by said inserted encryption tags.9. The computer program product according to claim 1, wherein saidencryption requirement further comprises specification of an encryptionalgorithm to be used when encrypting elements having that visibilitypolicy.
 10. The computer program product according to claim 1, whereinsaid encryption requirement further comprises specification of anencryption algorithm strength value to be used when encrypting elementshaving that visibility policy.
 11. The computer program productaccording to claim 1, wherein said computer-readable program code forcreating said output document further comprises: computer-readableprogram code for generating a distinct symmetric key for each unique oneof said communities identified by said visibility policy in said storedpolicy objects for each of said elements of said input document; andcomputer-readable program code for encrypting said distinct symmetrickeys separately for each of said members of said community for whichsaid symmetric key was generated, thereby creating member-specificversions of each of said distinct symmetric keys.
 12. The computerprogram product according to claim 11, wherein said computer-readableprogram code for encrypting each of said distinct symmetric keysseparately for each of said members uses a public key of said communitymember as input when creating each of said member-specific versions. 13.The computer program product according to claim 1, wherein saidencrypted elements in said created output document are encrypted using acipher block chaining mode encryption process.
 14. The computer programproduct according to claim 11, further comprising: computer-readableprogram code for creating a key class for each of said uniquecommunities, wherein said key class is associated with each of saidencrypted elements of said output document for which members of thisunique community are authorized viewers, and wherein said key classcomprises: (1) an encryption algorithm identifier and key length usedwhen encrypting said associated encrypted elements; (2) an identifier ofeach member of said unique community; and (3) one of saidmember-specific versions of said encrypted symmetric key for each ofsaid identified community members.
 15. The computer program productaccording to claim 11, further comprising: computer-readable programcode for decrypting, for an individual user or process, only thoseencrypted elements in said output document for which said individualuser or process is one of said authorized community members, furthercomprising: computer-readable program code for determining zero or moreof said communities of which said individual user or process is one ofsaid members; computer-readable program code for decrypting, for each ofsaid determined communities, said member-specific version of saidsymmetric key, thereby creating a decrypted key; and computer-readableprogram code for decrypting selected ones of said encrypted elements insaid output document using said decrypted keys, wherein said selectedones of said encrypted elements are those which were encrypted for oneof said determined communities.
 16. The computer program productaccording to claim 14, wherein said computer-readable program code forencrypting each of said distinct symmetric keys separately for each ofsaid members uses a public key of said community member as input whencreating each of said member-specific versions and further comprising:computer-readable program code for decrypting, for an individual user orprocess, only those encrypted elements in said output document for whichsaid individual user or process is one of said authorized communitymembers, further comprising: computer-readable program code fordetermining zero or more of said key classes which identify saidindividual user or process as one of said members; computer-readableprogram code for decrypting, for each of said determined key classes,said member-specific version of said encrypted symmetric key, using aprivate key of said individual user or process, thereby creating adecrypted key; and computer-readable program code for decryptingselected ones of said encrypted elements in said output document usingsaid decrypted keys, wherein said selected ones of said encryptedelements are those which were encrypted for one of said determined keyclasses.
 17. The computer program product according to claim 15 or claim16, further comprising computer-readable program code for substituting apredetermined text message for any encrypted elements in said outputdocument which cannot be decrypted for said individual user or process.18. The computer program product according to claim 1, wherein said DTDis replaced by a schema.
 19. The computer program product according toclaim 1, wherein said encryption requirement further comprisesspecification of an encryption key length.
 20. The computer programproduct according to claim 8, wherein said inserted encryption tags maysurround either values of said elements or values and tags of saidelements.
 21. A system for enforcing security policy using style sheetprocessing in a computing environment, comprising: an input document; aDocument Type Definition (DTD) that defines elements of said inputdocument, wherein: (1) an attribute of at least one element defined insaid DTD references one of a plurality of stored policy enforcementobjects; (2) more than one of said references may reference a singlestored policy enforcement object; and (3) each of said stored policyenforcement objects specifies a visibility policy for said referencingelement of elements, said visibility policy identifying an encryptionrequirement for all elements having that visibility policy and acommunity whose members are authorized to view those elements; means forapplying one or more style sheets to said input document, thereby addingmarkup notation to each element of said input document for which saidelement definition in said DTD references one of said stored policyenforcement objects specifying a visibility policy with a non-nullencryption requirement, resulting in creation of an interim transientdocument that indicates elements of said input document which are to beencrypted; and means for creating an output document in which eachelement of said interim transient document for which markup notation hasbeen added is encrypted in a manner that enables each community memberthat is authorized to view that element to use key distribution materialassociated with the output document to decrypt the encrypted element,and that precludes decryption of the encrypted element by unauthorizedcommunity members.
 22. The system according to claim 21, wherein saidmarkup notation in said interim transient document comprises tags of amarkup language.
 23. The system according to claim 21, wherein saidinput document is specified in an Extensible Markup Language (XML)notation.
 24. The system according to claim 23, wherein said outputdocument is specified in said XML notation.
 25. The system according toclaim 21, wherein said stored policy enforcement objects furthercomprise means for overriding a method for evaluating said elements ofsaid input document, and wherein said means for applying said one ormore style sheets further comprises means for invoking said means foroverriding, thereby causing said markup notation to be added.
 26. Thesystem according to claim 25, wherein said style sheets are specified inan Extensible Stylesheet Language (XSL) notation.
 27. The systemaccording to claim 26, wherein said method is a value-of method of saidXSL notation, and wherein said means for overriding said value-of methodis by subclassing said value-of method.
 28. The system according toclaim 25, wherein: said overriding method comprises: means forgenerating said markup notation as encryption tags; and means forinserting said generated encryption tags into said interim transientdocument to surround elements of said interim transient document forwhich said visibility policy of said elements in said input documenthave said, non-null encryption requirement; and said means for creatingsaid output document further comprises means for encrypting thoseelements surrounded by said inserted encryption tags.
 29. The systemaccording to claim 21, wherein said encryption requirement furthercomprises specification of an encryption algorithm to be used whenencrypting elements having that visibility policy.
 30. The systemaccording to claim 21, wherein said encryption requirement furthercomprises specification of an encryption algorithm strength value to beused when encrypting elements having that visibility policy.
 31. Thesystem according to claim 21, wherein said means for creating saidoutput document further comprises: means for generating a distinctsymmetric key for each unique one of said communities identified by saidvisibility policy in said stored policy objects for each of saidelements of said input document; and means for encrypting said distinctsymmetric keys separately for each of said members of said community forwhich said symmetric key was generated, thereby creating member-specificversions of each of said distinct symmetric keys.
 32. The systemaccording to claim 31, wherein said means for encrypting each of saiddistinct symmetric keys separately for each of said members uses apublic key of said community member as input when creating each of saidmember-specific versions.
 33. The system according to claim 21, whereinsaid encrypted elements in said created output document are encryptedusing a cipher block chaining mode encryption process.
 34. The systemaccording to claim 31, further comprising: means for creating a keyclass for each of said unique communities, wherein said key class isassociated with each of said encrypted elements of said output documentfor which members of this unique community are authorized viewers, andwherein said key class comprises: (1) an encryption algorithm identifierand key length used when encrypting said associated encrypted elements;(2) an identifier of each member of said unique community; and (3) oneof said member-specific versions of said encrypted symmetric key foreach of said identified community members.
 35. The system according toclaim 31, further comprising: means for decrypting, for an individualuser or process, only those encrypted elements in said output documentfor which said individual user or process is one of said authorizedcommunity members, further comprising: means for determining zero ormore of said communities of which said individual user or process is oneof said members; means for decrypting, for each of said determinedcommunities, said member-specific version of said symmetric key, therebycreating a decrypted key; and means for decrypting selected ones of saidencrypted elements in said output document using said decrypted keys,wherein said selected ones of said encrypted elements are those whichwere encrypted for one of said determined communities.
 36. The systemaccording to claim 34, wherein said means for encrypting each of saiddistinct symmetric keys separately for each of said members uses apublic key of said community member as input when creating each of saidmember-specific versions and further comprising: means for decrypting,for an individual user of process, only those encrypted elements in saidoutput document for which said individual user or process is one of saidauthorized community members, further comprising: means for determiningzero or more of said key classes which identify said individual user orprocess as one of said members; means for decrypting, for each of saiddetermined key classes, said member-specific version of said encryptedsymmetric key, using a private key of said individual user or process,thereby creating a decrypted key; and means for decrypting selected onesof said encrypted elements in said output document using said decryptedkeys, wherein said selected ones of said encrypted elements are thosewhich were encrypted for one of said determined key classes.
 37. Thesystem according to claim 35 or claim 36 further comprising means forsubstituting a predetermined text message for encrypted elements in saidoutput document which cannot be decrypted for said individual user orprocess.
 38. The system according to claim 21, wherein said DTD isreplaced by a schema.
 39. The system according to claim 21, wherein saidencryption requirement further comprises specification of an encryptionkey length.
 40. The system according to claim 28, wherein said insertedencryption tags may surround either values of said elements or valuesand tags of said elements.
 41. A method for enforcing security policyusing style sheet processing in a computing environment, comprising:providing an input document; providing a Document Type Definition (DTD)that defines elements of said input document, wherein: (1) an attributeof at least one element defined in said DTD references one of aplurality of stored policy enforcement objects; (2) more than one ofsaid references may reference a single stored policy enforcement object;and (3) each of said stored policy enforcement objects specifies avisibility policy for said referencing element of elements, saidvisibility policy identifying an encryption requirement for all elementshaving that visibility policy and a community whose members areauthorized to view those elements; applying one or more style sheets tosaid input document, thereby adding markup notation to each element ofsaid input document for which said element definition in said DTDreferences one of said stored policy enforcement objects specifying avisibility policy with a non-null encryption requirement, resulting increation of an interim transient document that indicates elements ofsaid input document which are to be encrypted; and creating an outputdocument in which each element of said interim transient document forwhich markup notation has been added is encrypted in a manner thatenables each community member that is authorized to view that element touse key distribution material associated with the output document todecrypt the encrypted element, and that precludes decryption of theencrypted element by unauthorized community members.
 42. The methodaccording to claim 41, wherein said markup notation in said interimtransient document comprises tags of a markup language.
 43. The methodaccording to claim 41, wherein said input document is specified in anExtensible Markup Language (XML) notation.
 44. The method according toclaim 43, wherein said output document is specified in said XMLnotation.
 45. The method according to claim 41, wherein said storedpolicy enforcement objects further comprise executable code foroverriding a method for evaluating said elements of said input document,and wherein said applying one or more style sheets to said inputdocument step further comprises overriding said method for evaluating,thereby causing said markup notation to be added.
 46. The methodaccording to claim 45, wherein said style sheets are specified in anExtensible Stylesheet Language (XSL) notation.
 47. The method accordingto claim 46, wherein said method is a value-of method of said XSLnotation, and wherein said overriding said value-of method is bysubclassing said value-of method.
 48. The method according to claim 45,wherein: said overriding further comprises: generating said markupnotation as encryption tags; and inserting said generated encryptiontags into said interim transient document to surround elements of saidinterim transient document for which said visibility policy of saidelements in said input document have said non-null encryptionrequirement; and said creating said output document further comprisesthe encrypting those elements surrounded by said inserted encryptiontags.
 49. The method according to claim 41, wherein said encryptionrequirement further comprises specification of an encryption algorithmto be used when encrypting elements having that policy.
 50. The methodaccording to claim 41, wherein said encryption requirement furthercomprises specification of an encryption algorithm strength value to beused when encrypting elements having that policy.
 51. The methodaccording to claim 41, wherein said creating said output documentfurther comprises: generating a distinct symmetric key for each uniqueone of said communities identified by said visibility policy in saidstored policy objects for each of said elements of said input document;and encrypting said distinct symmetric keys separately for each of saidmembers of said community for which said symmetric key was generated,thereby creating member-specific versions of each of said distinctsymmetric keys.
 52. The method according to claim 51, wherein saidencrypting each of said distinct symmetric keys separately for each ofsaid members uses a public key of said community member as input whencreating each of said member-specific versions.
 53. The method accordingto claim 41, wherein said encrypted elements in said created outputdocument are encrypting using a cipher block chaining mode encryptionprocess.
 54. The method according to claim 52, further comprising:creating a key class for each of said unique communities, wherein saidkey class is associated with each of said encrypted elements of saidoutput document for which members of this unique community areauthorized viewers, and wherein said key class comprises: (1) anencryption algorithm identifier and key length used when encrypting saidassociated encrypted elements; (2) an identifier of each member of saidunique community; and (3) one of said member-specific versions of saidencrypted symmetric key for each of said identified community members.55. The method according to claim 51, further comprising decrypting, foran individual user or process, only those encrypted elements in saidoutput document for which said individual user or process is one of saidauthorized community members, further comprising: determining zero ormore of said communities of which said individual user or process is oneof said members; decrypting, for each of said determined communities,said member-specific version of said symmetric key, thereby creating adecrypted key; and decrypting selected ones of said encrypted elementsin said output document using said decrypted keys, wherein said selectedones of said encrypted elements are those which were encrypted for oneof said determined communities.
 56. The method according to claim 54,wherein said encrypting said distinct symmetric keys separately for eachof said members uses a public key of said community member as input whencreating each of said member-specific versions and further comprising:decrypting, for an individual user or process, only those encryptedelements in said output document for which said individual user orprocess is one of said authorized community members, further comprising:determining zero or more of said key classes which identify saidindividual user or process as one of said members; decrypting, for eachof said determined key classes, said member-specific version of saidencrypted symmetric key, using a private key of said individual user orprocess, thereby creating a decrypted key; and decrypting selected onesof said encrypted elements in said output document using said decryptedkeys, wherein said selected ones of said encrypted elements are thosewhich were encrypted for one of said determined key classes.
 57. Themethod according to claim 55 or claim 56, further comprisingsubstituting a predetermined text message for any encrypted elements insaid output document which cannot be decrypted for said individual useror process.
 58. The method according to claim 41, wherein said DTD isreplaced by a schema.
 59. The method according to claim 41, wherein saidencryption requirement further comprises specification of an encryptionkey length.
 60. The method according to claim 48, wherein said insertedencryption tags may surround either values of said elements or valuesand tags of said elements.